Coffee machine Philips EP5444/90 5400 Series LatteGo

[DivanX10]

23.04.2023 purchased a new Philips EP5444/90 5400 Series LatteGo coffee machine and I'm going to repeat your experience. The withdrawal of the warranty does not frighten me, I can repair it myself if something happens to it. I would like to clarify about connecting the display to the ESP8266 WeMos D1 Mini. You write about the transistor, but you did not specify which transistor to connect.

Which transistor should I connect? I have a TIP120 transistor

This is how the wiring to the display looks, just like you do, which may have a chance to control remotely. Do you think it will work?

Do I understand correctly that it is necessary to disconnect this cable from the display, connect some of the wires to the ESP8266 WeMos D1 Mini, and already pull the wiring from the ESP8266 WeMos D1 Mini to the connector?

[TillFleisch]

I used a IRLZ44N mosfet, which I had laying around from a different project. Anything that can switch the 5v/gnd should be able to do the job. I don't have a background in electrical engineering so take that with a grain of salt.

The picoflex connector looks like the one on my machine. The esp is supposed to go in-between the display and the Mainboard. You can remove the connector or split the ribbon cable to achieve this.

That being said, I have no idea if this external component will work on your machine, as mine does not have a display. I'm guessing the inner workings on your machine are going to be different. On my machine the message sent on the bus contain led states and button press states. I cannot say if the behaviour or the messages are the same on your machine.

[DivanX10]

There are several transistors, which in your opinion are the most suitable and why did you use the IRLZ44N mosfet and not the BC33725TFR?

1. IRF520NPBF
2. BC33725TFR
3. BS170
4. BC337-40

[DivanX10]

Do I understand correctly?

1) ESP8266 is an intermediary between the control panel and the control board, and even if ESP8266 is without the esphome code, you can control the coffee machine as if there is no ESP8266

2) Commands from the coffee machine need to be caught in logs

3) If I solder a transistor, in my case it will be BS170, then can I remotely turn on the coffee machine and the screen will turn on?

4) Which wire is in the stranded cable? Easily amenable to tinning and soldering? Isn't there a thin wire inside? For example, as in wired headphones, the wire is thin and difficult to service, there is not such a wire here?

[TillFleisch]

There are several transistors, which in your opinion are the most suitable and why did you use the IRLZ44N mosfet and not the BC33725TFR?

I used the IRLZ44N because it was the one unused mosfet I had laying around. I cannot recommend a specific mosfet or transistor as I am not familiar enough with the related electronics topic.

ESP8266 is an intermediary between the control panel and the control board, and even if ESP8266 is without the esphome code, you can control the coffee machine as if there is no ESP8266

Yes, the ESP is an intermediary. Without the firmware generated by ESPHome the coffee machine will not work properly as the communication between the Display and Mainboard is stopped. This component will take anything on the display UART and forward it to the mainboard UART (and vice versa). In case youre machine uses different commands, but the same wiring, this component should not stop the machine from working (assuming the wiring is the same).

Commands from the coffee machine need to be caught in logs

You can use the ESPHome UART debug functionality to log the communication on the bus.

If I solder a transistor, in my case it will be BS170, then can I remotely turn on the coffee machine and the screen will turn on?

Maybe. Turning on the coffee machine is both a combination of sending a command and temporarily removing power from the display on my unit. I cannot say if the behavior will be the same on your device.

Which wire is in the stranded cable? Easily amenable to tinning and soldering? Isn't there a thin wire inside? For example, as in wired headphones, the wire is thin and difficult to service, there is not such a wire here?

On my machine the wiring inside the ribbon cable is stranded wiring which can be tinned and soldered easily. The wires inside the ribbon are small but not as small as headphone cables.

[DivanX10]

So, I connected it and it worked, but somehow strangely. It works both with a transistor and without a transistor. Since the BS170 and BC337-40 transistors are on the way and should arrive soon, I decided not to wait, but to use the existing IRF520 MOSFET. If you do not enable debugging (remove debug from the code:), then the screen turns on without a transistor and you can fully control the coffee machine, and through the ESPHome web interface, the Power switch is constantly on and off. It's the same with a transistor. The coffee machine does not pour coffee through ESP Home. Select play/pause does not work.

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

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

philips_series_2200:
  display_uart: uart_display
  mainboard_uart: uart_mainboard
  power_pin: GPIO12
  id: philip

If you enable debugging. The debugging code looks like this (see below), then when you try to press the button via the web ESPHome, the control panel on the coffee machine turns off, although there are logs in the ESPHome. Can you help me set up the esp to work with the coffee machine? How to understand from the log that the coffee machine is pouring coffee? Can you add a philip_series_5400 coffee machine to the component?

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

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

philips_series_2200:
  display_uart: uart_display
  mainboard_uart: uart_mainboard
  power_pin: GPIO12
  id: philip

[DivanX10]

I figured out how to create my component for the 5400 series, it remains to understand why the screen turns off when debugging. There is an assumption that the IRF520 MOSFET transistor does not open at 3.3V. As soon as I get the BS170 and BC337-40 transistor, I will check them in action.

As I understand how to split messages. We turn on the debugging mode, click on the buttons and see what message arrives in the esp, we break this message into parts and insert it in the same way as your version

https://github.com/TillFleisch/ESPHome-Philips-Smart-Coffee/blob/main/protocol.md

[TillFleisch]

Based on the uart logs it looks like the ep5444 is using a different protocol for communication. On my ep2220 all messages start with 'D5 55', this does not seem to be the case on your machine.

The protocol has been reverse engineered using the uart debug functionality. You can find more information on the messages in protocol.md.

Unfortunately, I cannot help you develop support for the ep5444 as I don't have access to that machine. To me it looks like this should be its own separate external component. Feel free to fork and modify this repository.

[DivanX10]

When debugging, I have very long numbers displayed. How did you prescribe to catch messages as shown in the screenshot? What code did you use?

If I specify such a code

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

then my messages will look like this

<<< AA:AA:AA:B5:F5:06:00:00:00:00:00:00:68:BE:A1:30:55:AA:AA:AA:B5:F3:06:00:00:00:00:00:00:EF:B7:CE:F6:55:AA:AA:AA:B0:F4:07:06:00:00:00:00:00:00:FA:4D:73:CF:55:AA:AA:AA:B5:F5:06:00:00:00:00:00:00:68:BE:A1:30:55:AA:AA:AA:B5:F3:06:00:00:00:00:00:00:EF:B7:CE:F6:55:AA:AA:AA:B0:F4:07:06:00:00:00:00:00:00:FA:4D:73:CF:55:AA:AA:AA:FF:04:01:04:69:84:3E:E6:55:AA:AA:AA:B5:F5:06:00:00:00:00:00:00:68:BE:A1:30:55
23:44:03    [D] [uart_debug:114]    
>>> 6C:75:55:AA:AA:AA:FF:F3:01:F3:83:86:6C:75:55:AA:AA:AA:FF:F3:01:F3:83:86:6C:75:55:AA:AA:AA:FF:F4
23:44:03    [D] [uart_debug:114]    
<<< AA:AA:AA:B5:F3:06:00:00:00:00:00:00:EF:B7:CE:F6:55:AA:AA:AA:B0:F4:07:06:00:00:00:00:00:00:FA:4D:73:CF:55:AA:AA:AA:B5:F5:06:00:00:00:00:00:00:68:BE:A1:30:55:AA:AA:AA:B5:F3:06:00:00:00:00:00:00:EF:B7:CE:F6:55:AA:AA:AA:B0:F4:07:06:00:00:00:00:00:00:FA:4D:73:CF:55:AA:AA:AA:B5:F5:06:00:00:00:00:00:00:68:BE:A1:30:55:AA:AA:AA:B5:F3:06:00:00:00:00:00:00:EF:B7:CE:F6:55:AA:AA:AA:B0:F4:07:06:00:00:00:00:00:00:FA:4D:73:CF:55
23:44:03    [D] [uart_debug:114]    
>>> F6:01:F6:E7:B0:CD:03:55
23:44:04    [D] [uart_debug:114]    
<<< AA:AA:AA:B5:F5:06:00:00:00:00:00:00:68:BE:A1:30:55:AA:AA:AA:B5:F3:06:00:00:00:00:00:00:EF:B7:CE:F6:55:AA:AA:AA:B0:F4:07:06:00:00:00:00:00:00:FA:4D:73:CF:55:AA:AA:AA:B5:F5:06:00:00:00:00:00:00:68:BE:A1:30:55:AA:AA:AA:B5:F3:06:00:00:00:00:00:00:EF:B7:CE:F6:55:AA:AA:AA:B0:F4:07:06:00:00:00:00:00:00:FA:4D:73:CF:55:AA:AA:AA:B5:F5:06:00:00:00:00:00:00:68:BE:A1:30:55
23:44:04    [D] [uart_debug:114]    
<<< AA:AA:AA:B5:F3:06:00:00:00:00:00:00:EF:B7:CE:F6:55:AA:AA:AA:B0:F4:07:06:00:00:00:00:00:00:FA:4D:73:CF:55:AA:AA:AA:BA:F6:18:FD:A1:01:00:CE:42:02:00:03:00:DE:26:E8:03:01:04:03:04:00:01:00:00:00:00:5F:93:11:D8:55:AA:AA:AA:B0:F7:07:06:00:00:00:00:00:00:3F:71:FE:F6:55:AA:AA:AA:B5:F8:06:00:00:00:00:00:FF:34:44:A6:86:55:AA:AA:AA:BA:F6:18:FD:A1:01:00:CE:42:02:00:03:00:DE:26:E8:03:01:04:03:04:00:01:00:00:00:00:5F:93:11:D8:55:AA:AA:AA:B0:F7:07:06:00:00:00
23:44:04    [D] [uart_debug:114]    

If I specify such a code

uart:
  # UART connected to the mainboard
 - tx_pin: GPIO1
   rx_pin: GPIO3
   baud_rate: 115200
   id: uart_mainboard
   debug:
     direction: TX
     after:
       bytes: 12
       timeout: 1s

then my messages will look like this. I press the buttons and I don't see a sequence, there is no such thing as numbers repeating

>>> A7:A7:F7:2D:55:AA:AA:AA:FF:4C:01:4C
00:04:51    [D] [uart_debug:114]    
>>> B3:91:B0:E0:55:A7:A7:4C:01:B3:91:E0
00:04:51    [D] [uart_debug:114]    
>>> 4F:50:7E:FF:7B:55:AA:AA:FF:4F:4F:50
00:04:51    [D] [uart_debug:114]    
>>> FF:7B:55:9D:9D:DD:5A:0D:CD:55:AA:AA
00:04:51    [D] [uart_debug:114]    
>>> AA:4F:01:50:7E:7B:55:AA:AA:4F:01:50
00:04:51    [D] [uart_debug:114]    
>>> 7E:FF:55:AA:AA:AA:FF:4F:01:4F:50:7E
00:04:51    [D] [uart_debug:114]    
>>> AA:AA:4F:01:50:7E:7B:55:A7:A7:01:4F
00:04:51    [D] [uart_debug:114]    
>>> 9D:DD:5A:0D:CD:AB:FF:AA:AA:4F:01:50

[DivanX10]

Tell me, how do you have a timer implemented? I turn on the coffee machine via the control panel, in the settings it is set to turn off after 180 minutes, and the esp turns off after 5-10 minutes. Is there any way to turn it off? Nothing is working for me yet and I'm trying to understand the sequence from the logs, but the coffee machine turns off and I have to turn it on. If I comment out this code, then I can't turn on the coffee machine and the control panel doesn't respond, but if I comment out, then the control panel works

philips_series_5400:
  display_uart: uart_display
  mainboard_uart: uart_mainboard
  power_pin: GPIO12
  id: philip

[DivanX10]

I reconnected the esp8266 wemos so as not to interfere with the control of the coffee machine and at the same time you can track bytes, try to find at least some logic in this

For debugging, I chose only the display to see what commands will be when you click on the screen

uart:
  # UART connected to the display
 - tx_pin: GPIO15
   rx_pin: GPIO13
   baud_rate:  115200
   id: uart_display
   debug:
     direction: TX
     after:
       bytes: 12
       timeout: 100 ms

It looks like this and it's not clear how you can figure it out. Can someone tell me how this is done

[TillFleisch]

How did you prescribe to catch messages as shown in the screenshot? What code did you use?

I did something similar to the wiring configuration you've commented above and listened to what the machine does.

the esp turns off after 5-10 minutes

This should not happen. Make sure it has stable power. Maybe the coffee machine disables power for the display after a given time period. With the new wiring configuration you can remove the custom component and use just the debug configuration. This may be more stable.

For debugging, I chose only the display to see what commands will be when you click on the screen

For debugging/reverse engineering the protocol I would recommended the following things:

• choose a larger buffer/more bytes, this makes detecting patterns easier
• remove the external component and use the uart dummy_receiver to reduce complexity
• make sure the baud rate is correct

[DivanX10]

I did as you said, turned everything off and left only the uart

uart:
  baud_rate: 115200
  rx_pin: GPIO3
  debug:
    dummy_receiver: true
    after:
      bytes: 12

And I saw something interesting, the data comes from the motherboard, not from the display

If I use the code below, then thanks to display_uart: uart_display I will have the right arrows displayed. Moreover, the wire I have is really connected to GPIO3, and nothing is connected to GPIO 13 and 15

external_components:
  - source:
      type: local
      path: components
    components: [philips_series_5400, philips_action_button, philips_power_switch, philips_status_sensor]

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

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

philips_series_5400:
  display_uart: uart_display
  mainboard_uart: uart_mainboard
  power_pin: GPIO12
  id: philip

I have some questions. 1) The data should be pouring from the display as well as from the motherboard, or is it displayed only when you press the buttons? 2) Do I understand correctly that it is not necessary to use display_uart: uart_display and the data from the display should arrive when the uart is turned on and if there is no data, then the wrong wire is connected? 3) How do you display data during debugging if you remove it?

philips_series_2200:
  display_uart: uart_display
  mainboard_uart: uart_mainboard
  power_pin: GPIO12
  id: philip

[DivanX10]

And the records look interesting, until I understood their logic. I describe my observations

the coffee machine is turned on and ready to work

Was in standby mode. As soon as I turned it off, everything became 00:00

I clicked on the make coffee button, but I could not get such records again

[TillFleisch]

The data should be pouring from the display as well as from the motherboard, or is it displayed only when you press the buttons?

On my ep2220 the display is constantly sending update requests to the Mainboard. If the machine is turned off, the display stops sending requests. This behaviour may be different on your machine.

Do I understand correctly that it is not necessary to use display_uart: uart_display and the data from the display should arrive when the uart is turned on and if there is no data, then the wrong wire is connected?

The display_uart: uart_display is required by this component as the uart reference is used to detect status updates. For reverse engineering the protocol you don't need the Philips component. You can use the uart debug functionality in combination with dummy receivers.

The wiring may be different on your machine. Thus the display and mainboard names may not be correct. The data looks pretty scrambled to me (in between the marked regions). Is the baud rate correct? Maybe you can verify the data lines(and baud raute) with an oscilloscope. I cannot really help you with reverse engineering the protocol tough, other than giving hints as to where to look :/

[DivanX10]

I cannot really help you with reverse engineering the protocol tough, other than giving hints as to where to look :/

You give good advice and it gives me a reason to think, so you even help a lot :smile:

[nighteagle1974]

Hello, i have also this project and bought a 5000 Philips - will give it try on Weekend with a ETH-32.

[DivanX10]

How did I find out that the motherboards of the 2000/3000/5000 series coffee machines are identical, only different control panels, so this connection scheme is the same for everyone, only the transistor is questionable. My screen turns on even without a transistor. The main problem is to catch the data from the management and I can't do it.

Motherboards of coffee machines of different series 1000/2000/3000/5000

### Motherboard of the 1000/2000/3000 series coffee machine   ### The motherboard of the 5000 series coffee machine 

Below I lay out the scheme for the board 1.9.30.330.00._v10

### Circuit for the board 1.9.30.330.00._v10  *** ### Communication with the front panel  *** ### Sensors and valves  *** ### Brewing device  *** ### High voltage outputs  *** ### Power supply system 

I'm trying to figure out from the logs what the command is for turning on coffee brewing and I still can't figure it out. I record by time and see the same records, but which one of them is responsible for the team, I do not see this

We put ESP Home on Windows, then I created a shortcut, specified the command cmd.exe and the path to esphome

Copy the project from ESPHome to the ESPHome folder on Windows and run the project

esphome logs smart-coffee-philips.yaml > philips5400_protocol.txt

Logs are recorded on the computer in a text file

[nighteagle1974]

Your posted shematic "Front Panel" is same as "Sensors"?

[DivanX10]

Your posted shematic "Front Panel" is same as "Sensors"?

What do you mean? If it's about sensors with this integration, then no, it doesn't work and the control doesn't work either. That's why I use debugging to find the commands in the logs that are responsible for sensors and controls, and at the moment nothing comes out for me. I haven't seen what the logs on the 2000 and 3000 series coffee machines look like to understand what to look for

[nighteagle1974]

Mean this: "Below I lay out the scheme for the board 1.9.30.330.00._v10" The first Shematic "Communication with the front panel" is same as "Sensors and valves" so i want a look to the wiring to the LCD and its communication but i see only sensors.

[DivanX10]

All circuits for the motherboard 1.9.30.330.00_v10.pdf

[nighteagle1974]

I have looked on your debbuged codes - it looks like the start and the stop of the message >> bytes not correct. On the first code overview this "Preamble AA AA etc" is on the beginning - the next is on the end or split in parts - looks like the Baudrate is not correct - it is more random when it starts... but it looks like it is a logic in this preamble. I will check this on weekend with my ozsilloskop - hope i find the time.

[nighteagle1974]

So is there some englich version instead of russia on the shematic-descriptors? Something is english and something not...

[DivanX10]

This information is not found on the Internet. I received it in the Russian-speaking community in telegram, where one person received these schemes through his connections. So that's what I posted. You can use a translator

[nighteagle1974]

Wonder how do you can translate this shematic - it is a image on pdf and i can not mark any letters... or words to copy to google. Somebody here can read this?

[TillFleisch]

@nighteagle1974 Maybe Google lens can help translate images.

..

I think the schematics are great but not necessary. Knowing that the panel-communication part is the same on all devices is good. Adding support for different machines basically comes down to reverse engineering the protocol used on the bus.

On the ep2220 the panel is constantly requesting status updates from the mainboard which responds with a status update. This update includes the status of all LEDs on the display. The status request message is essentially a list/map of all buttons and their states. When a button is pressed the content changes. You can find more information on the specific messages in the protocol.md file.

As @nighteagle1974 has pointed, the baud rate may be different. You can either verify with an oscilloscope or try other common baud rates.

[DivanX10]

I ordered and am waiting for the Fnirsi-1013D oscilloscope, it will arrive one of these days, I will try

[nighteagle1974]

Have you read this about your Fnirsi-1013D https://www.beis.de/Elektronik/FNIRSI-1013D/FNIRSI-1013D_de.html

[DivanX10]

I have read and watched reviews about this D1013 oscilloscope. He is the perfect option for me. I am not a radio engineer and programmer. I am fond of a smart home and sometimes I need an oscilloscope in addition to a multimeter. I bought it to be. I don't know how to use an oscilloscope yet, but I will learn over time, and the coffee machine finally gave me a reason to buy an oscilloscope that I didn't want to buy for a long time for the reason that I often don't need it.

[DivanX10]

So, I measured the coffee machine with an oscilloscope and a multimeter and that's what turned out. Since the 8-core wire has two colors, black and gray, I had to make a color scheme for convenience. I drew an up-to-date diagram for the 5400 series coffee machine. Since the 8-core wire has two colors black and gray, and the black color is +5v, then for convenience I made colored lines and numbered the wiring

Wiring diagram for the 5400 series coffee machine

 

Measurements with an oscilloscope

According to the calculation, the speed is 116279 bits / s I used the calculation formula F = 1/T 1) 8,6/1.000.000 = 0,0000086 2) 1/0,0000086=116 279,0697674419 = 116279 bits / s  

Now it remains to understand how to properly capture data from the coffee machine. Now I use this option for debugging

uart:
#UART connected to the display  
   rx_pin: GPIO3
   baud_rate: 116279
   stop_bits: 2
   data_bits: 8
   parity: EVEN
   debug:
    dummy_receiver: true
    after:
      bytes: 12
      timeout: 100 ms

In standby mode

[TillFleisch]

116279 sounds oddly specific. I would recommended averaging the measurement over a loner time period to reduce measurement error. Im guessing you will get closer to 115200 which is more common and also used on the ep2220.

[DivanX10]

116279 sounds oddly specific. I would recommended averaging the measurement over a loner time period to reduce measurement error. Im guessing you will get closer to 115200 which is more common and also used on the ep2220.

All right. The speed that I indicated, I calculated this speed after receiving the meander on the oscilloscope and this speed is close to the standard 115200, so we will indicate it as standard

I must have stumbled upon the necessary data. Here 's what I roughly came up with

55:AA:AA:AA:BA - this is data from the motherboard
55:AA:AA:AA:B0 - this is data from the motherboard
55:AA:AA:AA:B5 - this is data from the motherboard
55:AA:AA:AA:FF - this is data from the control panel

Previously found commands for buttons

55:AA:AA:AA:FF:07:01:07:8A:6B:71:7D - this is standby mode, do not press the buttons
55:AA:AA:AA:FF:0F:01:0F:00:B2:B9:7D - this is standby mode, do not press the buttons
55:AA:AA:AA:FF:07:01:07:B1:AD:F5 - this is the "Espresso" button
55:AA:AA:AA:FF:07:01:07:8A:AD:F5 - this is the "Espresso" button
55:AA:AA:AA:FF:07:01:90:6C:2B:F5 - this is the "Coffee" button - one serving
55:AA:AA:AA:FF:07:40:90:6C:2B:F5 - this is the "Coffee" button - a double portion

To see the data from the control panel when we press the buttons, you need to enable debugging from the motherboard

uart:
   rx_pin: GPIO13
   baud_rate: 115200
   id: uart_mainboard
   stop_bits: 1
   data_bits: 8
   parity: none
   debug:
    dummy_receiver: true

ESP8266 connection diagram for reading data from the motherboard

If we catch data from the control panel, then a lot of garbage arrives, which was thrown off earlier and the sequence was not traced. Therefore, we will comment it out or delete it

#uart:
# - rx_pin: GPIO3
#   baud_rate: 115200
#   id: uart_display
#   stop_bits: 1
#   data_bits: 8
#   parity: none
#   debug:
#    dummy_receiver: true

When I started reading data from the motherboard, I found a sequence and even probably found button commands. I made log entries several times, pressed the "Coffee" button, and every time I find this data

[02:21:57][D][uart_debug:114]: <<< 02:00:03:00:DE:26:E8:03:01:04:03:05:00:01:00:00:00:00:2B:B2:02:6D:55:AA:AA:AA:B0:32:07:06:00:00:00:00:00:64:79:92:71:4E:55:AA:AA:AA:FF:07:01:07:8A:AD:F5:55:FF:AA:AA:AA:B5:33:06:1D:00:00:00:00:00:9D:E1:20:33:55:AA:AA:AA:BA:34:18:DD:7B:01:00:EE:68:02:00:03:00:DE:12:6F:01:04:03:05:00:01:00:00:00:00:62:82:8B:A0:55:AA:AA:AA:B0:35:07:06:00:00:00:00:00:64:B0:FF:10:2A:55:AA:AA:AA:B5:36:06:1D:00:00:00:00:00:F9:EF:C0:7B:55:AA:AA:AA:BA:37:18:DD:7B:01:00:EE

---

If you translate the commands for the buttons into an array of bytes

Standby mode, do not press the buttons 55:AA:AA:AA:FF:07:01:07:8A:6B:71:7D = {0x55, 0xAA, 0xAA, 0xAA, 0xFF, 0x07, 0x01, 0x07, 0x8A, 0x6B, 0x71, 0x7D}

Standby mode, do not press the buttons 55:AA:AA:AA:FF:0F:01:0F:00:B2:B9:7D = { 0x55, 0xAA, 0xAA, 0xAA, 0xFF, 0x0F, 0x01, 0x0F, 0x00, 0xB2, 0xB9, 0x7D}

The "Espresso" button 55:AA:AA:AA:FF:07:01:07:B1:AD:F5 = {0x55, 0xAA, 0xAA, 0xAA, 0xFF, 0x07, 0x01, 0x07, 0xB1, 0xAD, 0xF5}

The "Espresso" button 55:AA:AA:AA:FF:07:01:07:8A:AD:F5 = {0x55, 0xAA, 0xAA, 0xAA, 0xFF, 0x07, 0x01, 0x07, 0x8A, 0xAD, 0xF5}

"Coffee" button - one serving 55:AA:AA:AA:FF:07:01:90:6C:2B:F5 = {0x55, 0xAA, 0xAA, 0xAA, 0xFF, 0x07, 0x01, 0x90, 0x6C, 0x2B, 0xF5}

The "Coffee" button is a double portion 55:AA:AA:AA:FF:07:40:90:6C:2B:F5 = {0x55, 0xAA, 0xAA, 0xAA, 0xFF, 0x07, 0x40, 0x90, 0x6C, 0x2B, 0xF5}

---

How do I create a sensor so that when I press the button on the coffee machine, it displays that I have chosen Espresso or Coffee? This will be useful to check if I found the bytes correctly. If true, then when you click on the control panel, the sensor will display which button I pressed Espresso or Coffee. Can you help?

[DivanX10]

I have moved a little and have already found something and even made a test sensor, but there are problems. I made a table with a transcript. This is what I found and still keep looking for commands

To check this or that command, I created a sensor, but for some reason it shows only waiting, and does not show the pressed buttons, although these bytes are in the logs. Apparently I made a mistake in the code or the code is not correct at all. Could you help make a sensor to check commands?

uart:
- rx_pin: GPIO13
  baud_rate: 115200
  id: uart_mainboard
  stop_bits: 1
  data_bits: 8
  parity: none
  debug:
   dummy_receiver: true
   sequence:
     - lambda: |-
          UARTDebug::log_hex(direction, bytes, ':'); //we specify this if we want to see debugging logs, if it is not necessary, then delete or comment out
          if (bytes[0]==0x55 && bytes[1]==0xAA && bytes[2]==0xAA && bytes[3]==0xAA && bytes[4]==0xFF) {
            if(bytes[5]==0x00 && bytes[7]==0x00 && bytes[11]==0xE6)
              id(idButtonSensor).publish_state("OFF");            
            if(bytes[8]==0xB1 && bytes[9]==0xAD && bytes[10]==0xF5)
              id(idButtonSensor).publish_state("Espresso X1");
            if(bytes[8]==0x6C && bytes[9]==0x2B && bytes[10]==0xF5)
              id(idButtonSensor).publish_state("Coffee X1");
            if(bytes[8]==0x8A && bytes[9]==0xAD && bytes[10]==0xF5)
              id(idButtonSensor).publish_state("Button (8A AD)");  
           }

text_sensor:
  - platform: template
    id: idButtonSensor
    name: Sensor button coffee
    update_interval: 60s

[nighteagle1974]

So for me it should be like this:

        if(bytes[5]==0x00 && bytes[7]==0x00 && bytes[11]==0xE6) {
          id(idButtonSensor).publish_state("OFF"); }

Because the command is: if (check something) { here the Block do something; }

[DivanX10]

So for me it should be like this:

        if(bytes[5]==0x00 && bytes[7]==0x00 && bytes[11]==0xE6) {
          id(idButtonSensor).publish_state("OFF"); }

Because the command is: if (check something) { here the Block do something; }

I understood what the problem was. The problem is that I had one sensor and the "Waiting" record was overwriting the other records, so I created a second sensor. In a good way, it will be necessary to separate the sensor state from the buttons, but I can do this when I fill the table with enough data, and now I have little data. Thanks to the status sensor, I saw that the Modes (I renamed Waiting to Mode) are changing. When you turn on the coffee machine and make coffee, the modes change and, accordingly, the commands for mode 1 are not visible if mode 3. I don't understand the logic yet, what it is and why it happens, and it's not yet clear why pressing the buttons is not always in the logs, as if a failure occurs and commands are not sent to the motherboard or the esp does not have time to catch them. There are a lot of questions so far.

- rx_pin: GPIO13
  baud_rate: 115200
  id: uart_mainboard
  stop_bits: 1
  data_bits: 8
  parity: none
  debug:
   dummy_receiver: true
   sequence:
    - lambda: |-
        UARTDebug::log_hex(direction, bytes, ':');
        if (bytes[0]==0x55 && bytes[1]==0xAA && bytes[2]==0xAA && bytes[3]==0xAA && bytes[4]==0xFF) {
          if (bytes[9]==0x6B && bytes[10]==0x71 && bytes[11]==0x7D) id(idSystemNum).publish_state("Mode 1");
          if (bytes[9]==0xB2 && bytes[10]==0xB9 && bytes[11]==0x7D) id(idSystemNum).publish_state("Mode 2");
          if (bytes[9]==0xDE && bytes[10]==0xFB && bytes[11]==0x90) id(idSystemNum).publish_state("Mode 3");
          if (bytes[9]==0xDE && bytes[10]==0xDD && bytes[11]==0x7D) id(idSystemNum).publish_state("Mode 4");
          if (bytes[9]==0x6B && bytes[10]==0x57 && bytes[11]==0x90) id(idSystemNum).publish_state("Mode 5");
          if (bytes[5]==0x00 && bytes[7]==0x00 && bytes[11]==0xE6) id(idButtonSensor).publish_state("OFF");
          if (bytes[8]==0xB1 && bytes[9]==0xAD && bytes[10]==0xF5) id(idButtonSensor).publish_state("Espresso X1");
          if (bytes[8]==0x6C && bytes[9]==0x2B && bytes[10]==0xF5) id(idButtonSensor).publish_state("Coffee X1");
          if (bytes[8]==0x8A && bytes[9]==0xAD && bytes[10]==0xF5) id(idButtonSensor).publish_state("Button (8A AD)");
          if (bytes[8]==0xC8 && bytes[9]==0xB7 && bytes[10]==0x90) id(idButtonSensor).publish_state("Button (С8 B7)");
          if (bytes[8]==0xCE && bytes[9]==0xB7 && bytes[10]==0x90) id(idButtonSensor).publish_state("Button (CE B7)");
        }

text_sensor:
  - platform: template
    id: idButtonSensor
    name: Sensor button coffee
    update_interval: 1s

  - platform: template
    id: idSystemNum
    name: System Number
    update_interval: 30s

I supplement the table and decorated it. On the table that is highlighted in orange, these are commands caught when the coffee machine is in mode 1, but if the coffee machine is in a different mode, then the commands are different and I don't see them yet. For example, for Mode 3, which is green, I managed to find something and I marked them as buttons with bytes, but it is not yet clear what they are responsible for

[nighteagle1974]

In one line the "if statement" is okay - above you have wrote in two lines - that is not okay. if (bytes[8]==0xCE && bytes[9]==0xB7 && bytes[10]==0x90) id(idButtonSensor).publish_state("Button (CE B7)");

[TillFleisch]

Are you only looking at data going from the motherboard to the display? Is row 14 (Espesso X1) only appearing once in the logs when you press the button?

I see two possible szenarios regarding row 14:

1. The 10 bytes are going from the display to the motherboard indicating that the espresso button has been pressed.
2. The 10 bytes are going from the motherboard to the display indicating that the "espresso selected page" should be shown

On the EP2220 the display status is constantly being updated. Maybe this is different on the 5400 and only the state change (changing the displayed page/content) is transmitted.

Now that you've found some code with a meaning you could try the following: Incject the 10 byte (Espresso X1) message into the line and observe what happens. Depending on where data is going 2 things could happen.

1. You've tricked the machine into selecting 'espresso' and the machine tells the display to show this change
2. You've tricked the display into showing the 'espresso' page (assuming the data is going to the display). (sadly, this does not tell us in which direction data is flowing)

It could also be the case that the protocol is entirely different, and that the display unit works by itself (this is not the case on the EP2220). This would mean that button presses are not sent to the mainboard, but instead instructions to brew coffee. Turning on the display unit without a connection to the mainboard could give more insight into the behaviour.

[nighteagle1974]

Do you mean the modes are the profiles of the coffeemachine? So my have blue, green, purple, yellow and nothing as a profile. If you change the profile the amount of coffee, water or the other profile-specific things change - so this indicate your changed bytes - it looks like this the bytes for amount of coffee, water and so on...

[DivanX10]

Do you mean the modes are the profiles of the coffeemachine? So my have blue, green, purple, yellow and nothing as a profile. If you change the profile the amount of coffee, water or the other profile-specific things change - so this indicate your changed bytes - it looks like this the bytes for amount of coffee, water and so on...

Yes, I also think that these are profiles (blue, green, pink, yellow and guest), but there are oddities here that I don't understand. I turn on the coffee machine, first mode 1 is displayed (you can call it whatever you want), then I use the blue profile and press the buttons. After I make coffee, the sensor shows mode 4, while I did not change the profile. Therefore, at the moment I cannot understand why this is happening.

[nighteagle1974]

First - after power up Mode 1 is active - then you press blue and then Mode 4 is active?

[DivanX10]

First - after power up Mode 1 is active - then you press blue and then Mode 4 is active?

When I turned on the coffee machine, I recorded the logs and saw the sequence

The stage of turning on the coffee machine

55:AA:AA:AA:FF:01:01:01:0D:B2:9F:90
55:AA:AA:AA:FF:02:01:02:EE:5D:D0:0B
55:AA:AA:AA:FF:03:01:03:4F:07:15:7D
55:AA:AA:AA:FF:04:01:04:69:84:3E:E6
55:AA:AA:AA:FF:05:01:05:C8:44:18:E2:6F:01:00:E9:74:02:00:03:00:DE:26:E8:03:01:04:03:0C:00:01:00:00:00:00:F4:6B:07:A5
55:AA:AA:AA:FF:06:01:06:2B:31:B4:0B
55:AA:AA:AA:FF:07:01:07:8A:6B:71:7D - here it is the mode 1, which then changes to 4 after making coffee

Here is the full log when you turn on the coffee machine. You can copy it to notepad and use the search for bytes that are listed above and see for yourself how the download is going, so these are not profiles

philips5400 turning on the coffee machine logging.txt

[DivanX10]

@TillFleisch I forgot to tell you. Without your component, the coffee machine does not turn on at all by pressing the power button, and if you use your component, it turns on. It's like there's something in your code that allows you to communicate between the motherboard and the screen. Is it possible to specify this in esphome without a component? What code is needed so that the motherboard and the screen can communicate as if there is no esp?

[TillFleisch]

This component performs man in the middle attack and forwards all data from the display to the Mainboard and vice versa. (Assuming the wiring is as shown in the diagram)

It looks like siieb's uart man in the middle component could to the job for you without any of the other things my Philips component adds.

[DivanX10]

For convenience, I created a table with data decryption, this may help to better understand the management of the coffee machine in the future

Table of decrypted commands https://docs.google.com/spreadsheets/d/1sTzoOKqZz0mQ03b2MuSvGPngoa127Qm1B61rXfeZFx0/edit?usp=sharing

[DivanX10]

In search of service documentation for the 5400 series, I found service documentation for the 1200-2200-3200 series. This may be useful to someone

[DivanX10]

To debug two UARTs at the same time, it is best to use ESP32. ESP8266 has one hardware uart and if you use two uarts on ESP8266, ESP8266 often freezes, which forced me to switch to ESP32. ESP32 copes with this perfectly, since ESP32 has support for 2 or 3 hardware uarts. The component uart_mitm which offered TillFleisch an excellent solution. I was able to embed ESP32 and thanks to uart_mitm, the coffee machine turns on, but it is very important not to include dummy_receiver: true in the configuration, we strictly specify dummy_receiver: false. If this is not done, the coffee machine will turn off. Read more here. Since I didn't find the bytes to control the coffee machine, I can't say whether all such transistors are needed or not. At the moment, everything turns on without a transistor.

Current ESP32 connection diagram without transistor

Below is the code for debugging

external_components:
  - source:
      type: git
      url: https://github.com/ssieb/custom_components
    components: [ uart_mitm ]

uart_mitm:
  uart1: uart_display
  uart2: uart_mainboard

uart:
#UART connection to the control panel. We read the data from the control panel and send it to the motherboard
 - rx_pin: GPIO16 #Reading data from the control panel
   tx_pin: GPIO17 #We send the data to the control panel
   baud_rate: 115200
   id: uart_display
   stop_bits: 1
   data_bits: 8
   parity: none
   debug:
     direction: BOTH
     dummy_receiver: false

#UART connection to the motherboard. We read the data from the motherboard and send it to the control panel
 - rx_pin: GPIO3 #Reading data from the motherboard
   tx_pin: GPIO1 #We send data to the motherboard
   baud_rate: 115200
   id: uart_mainboard
   stop_bits: 1
   data_bits: 8
   parity: none
   debug:
     direction: BOTH
     dummy_receiver: false

[DivanX10]

So, I got the Saleae logic analyzer and got the data when I turned on the coffee machine. the control panel was completely disconnected from the motherboard and when you press the turn on button, the coffee machine will not turn on.

Connected the logic analyzer in this way

In the analyzer settings, I chose 100M 2MHz. I connected the analyzer to the tablet and this is in order not to disable the coffee machine and desktop computer. The coffee machine does not have a galvanic isolation, which is fraught with disabling the computer connected to the outlet and the coffee machine itself, therefore, either with a laptop from the battery or on a tablet

Screenshots

      

Thus it comes out

1) AA:AA:AA:FE:00:00:C8:87:1B:40:55 2) AA:AA:AA:FF:00:01:00:AC:E8:5A:E6:55 3) AA:AA:AA:FF:00:01:00:AC:E8:5A:E6:55 4) AA:AA:AA:FF:00:01:00:AC:E8:5A:E6:55 5) AA:AA:AA:FF:00:01:00:AC:E8:5A:E6:55 6) AA:AA:AA:FF:00:01:00:AC:E8:5A:E6:55 7) AA:AA:AA:FF:00:01:00:AC:E8:5A:E6:55 8) AA:AA:AA:FF:00:01:00:AC:E8:5A:E6:55 9) 00

If you look at the logs of turning on the coffee machine, then there are these bytes. The logs themselves can be found in the folder 17-05-2023. Watch here

I tried to send commands to turn on, but the coffee machine does not turn on. How to correctly understand which command should be sent to enable?

button:
  - platform: template
    name: "Button 1"
    on_press:
      - uart.write:
          id: uart_mainboard
          data: [0xAA, 0xAA, 0xAA, 0xFE, 0x00, 0x00, 0xC8, 0x87, 0x1B, 0x40, 0x55] 

  - platform: template
    name: "Button 2"
    on_press:
      - uart.write:
          id: uart_mainboard
          data: [0xAA, 0xAA, 0xAA, 0xFF, 0x00, 0x01, 0x00, 0xAC, 0xE8, 0x5A, 0xE6, 0x55] 

  - platform: template
    name: "Button 3"
    on_press:
      - uart.write:
          id: uart_mainboard
          data: [0x00]

  - platform: template
    name: "Button 4"
    on_press:
      - uart.write:
          id: uart_display
          data: [0xAA, 0xAA, 0xAA, 0xFE, 0x00, 0x00, 0xC8, 0x87, 0x1B, 0x40, 0x55, 0xAA, 0xAA, 0xAA, 0xFF, 0x00, 0x01, 0x00, 0xAC, 0xE8, 0x5A, 0xE6, 0x55, 0xAA, 0xAA, 0xAA, 0xFF, 0x00, 0x01, 0x00, 0xAC, 0xE8, 0x5A, 0xE6, 0x55, 0xAA, 0xAA, 0xAA, 0xFF, 0x00, 0x01, 0x00, 0xAC, 0xE8, 0x5A, 0xE6, 0x55, 0xAA, 0xAA, 0xAA, 0xFF, 0x00, 0x01, 0x00, 0xAC, 0xE8, 0x5A, 0xE6, 0x55, 0xAA, 0xAA, 0xAA, 0xFF, 0x00, 0x01, 0x00, 0xAC, 0xE8, 0x5A, 0xE6, 0x55, 0xAA, 0xAA, 0xAA, 0xFF, 0x00, 0x01, 0x00, 0xAC, 0xE8, 0x5A, 0xE6, 0x55, 0xAA, 0xAA, 0xAA, 0xFF, 0x00, 0x01, 0x00, 0xAC, 0xE8, 0x5A, 0xE6, 0x55, 0x00] 

[TillFleisch]

The first image (wiring diagram) implies you've connected the logic analizer to the RX pin on the display. If this would be the case you shouldn't measure anything (assuming the display is disconnected from the motherboard).

If you want to perform a replay attack I would suggest sending multiple copies of the message, just in case something gets scrambled. Note that button 4 sends the message to the display instead of the Mainboard.

It looks like AA:AA:AA:FF:00:01:00:AC:E8:5A:E6:55 is the first command sent after turning on the display. Maybe there is something else required to turn on the Mainboard/coffee machine (i.e. a sequence of command, some sort of handshake(I think this is quite unlikely)).

Does something happen on the other data lines while turning on the coffee machine? (Or can we assume that this is not the case due to the schematic posted earlier?)

[DivanX10]

@TillFleisch

1) I connected according to this scheme. I broke the connection between the screen and the motherboard in order to see what signals the screen sends and found out that the screen sends only the power button, there is no reaction to other buttons

An example of turning on a coffee machine from the screen, the motherboard is silent, there is no response from it

You can see the following data

0000000000 AA AA AA FE 00 00 C8 87 1B 40 55 AA AA AA FF 00 .........@U..... 0000000010 01 00 AC E8 5A E6 55 AA AA AA FF 00 01 00 AC E8 ....Z.U......... 0000000020 5A E6 55 AA AA AA FF 00 01 00 AC E8 5A E6 55 AA Z.U.........Z.U. 0000000030 AA AA FF 00 01 00 AC E8 5A E6 55 AA AA AA FF 00 ........Z.U..... 0000000040 01 00 AC E8 5A E6 55 AA AA AA FF 00 01 00 AC E8 ....Z.U......... 0000000050 5A E6 55 AA AA AA FF 00 01 00 AC E8 5A E6 55 00 Z.U.........Z.U.

---

2) I specifically indicated sending a command to the screen to see what would happen and whether the screen would respond

button:
  - platform: template
    name: "Button 4"
    on_press:
      - uart.write:
          id: uart_display
          data: [0xAA, 0xAA, 0xAA, 0xFE  ..... ]

In case of sending to the motherboard, there is a response from the motherboard, but the coffee machine does not turn on

button:
  - platform: template
    name: "Button 3"
    on_press:
      - uart.write:
          id: uart_mainboard
          data: [0xAA, 0xAA, 0xAA, 0xFF, 0x00, 0x01, 0x00, 0xAC, 0xE8, 0x5A, 0xE6, 0x55] 

---

3) By connecting the logic analyzer in parallel according to this scheme, I was able to see the data from the screen and from the motherboard

Example of turning on a coffee machine

Display, canonical.txt Display, plain.txt Display, with offset.txt Motherboard, canonical.txt Motherboard, plain.txt Motherboard, with offset.txt

---

4) The data indicates that the activation is answered by the command either AA AA AA FE 00 00 C8 87 1B 40, or 55 AA AA AA FF 00 01 00 AC E8 5A E6, or AA AA AA FE 00 00 C8 87 1B 40 55 AA AA AA FF 00 01 00 AC E8 5A E6, but none of the commands work. I had doubts that the ESPHome does not send a signal, but after checking with a logical analyzer (connection diagram below), the question disappeared. ESPHome sends a signal and the logical analyzer caught the bytes and the bytes were transmitted correctly. I'm missing something and I can't figure out what, and I don't see any other options. I really need help. Thank you.

1) The coffee machine with this command AA AA AA FE 00 00 C8 87 1B 40 does not turn on

button:
  - platform: template
    name: "Button 1"
    on_press:
      - uart.write:
          id: uart_mainboard
          data: [0xAA, 0xAA, 0xAA, 0xFE, 0x00, 0x00, 0xC8, 0x87, 0x1B, 0x40, 0x55]

2) The coffee machine with this command 55 AA AA AA FF 00 01 00 AC E8 5A E6 does not turn on

button:
  - platform: template
    name: "Button 2"
    on_press:
      - uart.write:
          id: uart_mainboard
          data: [0xAA, 0xAA, 0xAA, 0x93, 0x00, 0x01, 0x01, 0x81, 0x90, 0xAD, 0xE0, 0x55]

3) The coffee machine with this command AA AA AA FE 00 00 C8 87 1B 40 55 AA AA AA FF 00 01 00 AC E8 5A E6 does not turn on

button:
  - platform: template
    name: "Button 3"
    on_press:
      - uart.write:
          id: uart_mainboard
          data: [0xAA, 0xAA, 0xAA, 0xFE, 0x00, 0x00, 0xC8, 0x87, 0x1B, 0x40, 0x55, 0xAA, 0xAA, 0xAA, 0xFF, 0x00, 0x01, 0x00, 0xAC, 0xE8, 0x5A, 0xE6, 0x55]

I upload all the files here, schemas, logs from esphome, records from the logic analyzer, decoded files

PS: As I noticed later that when the uart_mitm component is running, the coffee machine turns off after 20-22 minutes, which forced me to abandon the uart_mitm component and given the knowledge that dummy_receiver: false should be turned off in the uart_mitm component, then I decided to try it in your component and it worked, the coffee machine now turns on and does not turn off during the entire waiting time. I specified 180 minutes. Here is my code using your component.

logger:
  level: DEBUG
  baud_rate: 0

external_components:
  - source: github://TillFleisch/ESPHome-Philips-Smart-Coffee@main

uart:
# UART connected to the display
 - id: uart_display
   rx_pin: GPIO16
   tx_pin: GPIO17
   baud_rate: 115200
   stop_bits: 1
   data_bits: 8
   parity: NONE
   rx_buffer_size: 256
   debug:
     direction: BOTH
     dummy_receiver: false

# UART connected to the mainboard
 - id: uart_mainboard
   rx_pin: GPIO3
   tx_pin: GPIO1
   baud_rate: 115200
   stop_bits: 1
   data_bits: 8
   parity: NONE
   rx_buffer_size: 256
   debug:
     direction: BOTH
     dummy_receiver: false

philips_series_2200:
  display_uart: uart_display
  mainboard_uart: uart_mainboard
  power_pin: GPIO12
  id: philip

I also learned by experience that if we cut the ESP into the coffee machine, then any deviation in these parameters leads to the fact that the coffee machine does not turn on at all, not to mention the control. These parameters are standard and are used by default in the ESPHome settings and you can omit them

   baud_rate: 115200
   stop_bits: 1
   data_bits: 8
   parity: NONE

[DivanX10]

I tried to export to HEX in the PulseView program and that's what I got, is there something to catch on to?

Display:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
Motherboard:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
Display:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
Motherboard:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
Display:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
Motherboard:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
Display:00 00 00 00 03 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
Motherboard:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
Display:ff ff ff ff fe 00 00 00 00 3f ff e0 00 0f ff fc 00 01 ff ff 00 00 3f ff 
Motherboard:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
Display:ff ff ff ff 80 00 00 00 0f ff f8 00 03 ff ff 00 00 7f ff c0 00 0f ff ff 
Motherboard:00 00 00 00 00 00 00 00 00 00 01 ff ff ff ff ff ff ff ff ff ff ff ff ff 
Display:ff ff ff e0 00 00 00 03 ff fe 00 00 ff ff c0 00 1f ff f8 00 03 ff ff ff 
Motherboard:ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
Display:ff ff f8 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
Motherboard:ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
Display:ff fe 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1f ff ff 
Motherboard:ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
Display:ff 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 07 ff ff ff 
Motherboard:ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
Display:e0 00 00 00 00 00 00 00 00 7f ff c0 00 00 00 07 ff ff ff ff ff ff ff f8 
Motherboard:ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
Display:00 01 ff ff ff ff ff ff e0 00 00 00 00 00 00 00 00 ff ff ff ff ff fe 00 
Motherboard:ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
Display:00 7f ff ff ff e0 00 07 ff ff ff fe 00 00 00 00 00 00 1f ff ff ff 80 00 
Motherboard:ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
Display:00 00 00 00 00 00 00 00 00 00 00 00 00 1f ff f0 00 07 ff ff ff e0 00 07 
Motherboard:ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
Display:ff fc 00 01 ff ff 80 00 3f ff e0 00 07 ff fc 00 01 ff ff ff f8 00 00 00 
Motherboard:ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
Display:00 ff ff 80 00 1f ff f0 00 07 ff fe 00 00 ff ff ff ff ff fe 00 00 00 00 
Motherboard:ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
Display:3f ff e0 00 07 ff fc 00 01 ff ff 80 00 3f ff ff ff ff ff 80 00 00 00 0f 
Motherboard:ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
Display:ff f8 00 01 ff ff 00 00 7f ff e0 00 0f ff ff ff ff ff e0 00 07 ff ff ff 
Motherboard:ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
Display:ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff fc 00 00 00 00 00 00 
Motherboard:ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
Display:00 00 00 00 00 00 00 00 00 00 00 00 00 3f ff ff ff 00 00 7f ff c0 00 00 
Motherboard:ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
Display:00 00 00 00 00 00 00 00 00 00 00 00 0f ff ff ff c0 00 00 00 00 00 00 00 
Motherboard:ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
Display:00 00 00 00 00 00 00 00 00 00 00 03 ff ff ff f0 00 00 00 00 00 00 ff ff 
Motherboard:ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
Display:ff ff c0 00 0f ff f8 00 01 ff ff ff ff ff fc 00 00 00 00 00 00 00 00 1f 
Motherboard:ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
Display:ff f8 00 03 ff ff ff ff ff ff ff ff ff ff 00 00 00 00 3f ff f0 00 07 ff 
Motherboard:ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
Display:ff ff ff 00 00 7f ff e0 00 0f ff ff ff c0 00 00 00 07 ff ff ff ff 00 00