You didn’t really state what you are trying to achieve, nor did you state how much you know about HW and SW components, or what tools you have and how well you know how to use them.
I have a heat pump water heater and it has a digital controller and the ability to connect it to the Internet. I was not really interested in controlling it, but I was interested in seeing if I could figure out what it was doing. This was not an easy project. I started with finding the schematic (which was nicely provided on the WH itself). I can’t over estimate how much easier this made the (what was still a hard) project. With the schematic, I knew that there were several temperature sensors. So my goal was trivial. I wanted to get the data from those sensors. That was it, anything more would be a bonus.
The schematic said there were RS485 data lines going to a connection and 5V (to power the optional network controller). The first thing I did was get out my DVM and measure the various pins to make sure I understood what was what. This is critical because some of the pins have 240VAC on them, which will kill you if you are not careful.
I found the 5V logic pins and it looked like there was a pin that was outputting something. I then got my oscilloscope to see the shape of the data. It looked digital. I then got out my logic analyzer and captured some data. I was lucky that the WH is very chatty so there was lots of data. My logic analyzer was unable to automatically make sense of the data. It certainly looked like UART data, but it wasn’t quite right. I then had to spend some time pondering the signal and counting the bits. It was then that I realized there were 9 data bits and 1 stop bit. This is not terribly surprising for RS485, but I am not an expert in that form of communication so it took me a little while to figure it out (completely obvious now).
Once I had the basic data format, I wrote a simple program to print out the data to see if I could make any sense of it. This took awhile to figure out that it was using a packet format. Then more time to understand the different packets and what the data meant.
So, think about what you are really trying to achieve and how much effort you are willing to put into it. There have been a few reverse engineering projects where I decided I really didn’t need to know, since I wasn’t willing to put the effort into it. But, most of the time, I have found someone else was willing to put in the effort to figure it out and then generous enough to document it well enough for others to easily follow. It appears no one has done that yet for your exact controller.
As @Karosm said many buttons are controlled by a button that shorts a pin to ground. That is pretty easy to automate, but usually you need to see what is going on to make sense. More than a decade ago years before the esp8266 was a gleam is some designers eye, I created some automation that used the RF wireless switches. I first started by hacking the remotes (adding wires to let my MCU push the buttons). Many of the controllers of the time had one button that switched the state of the relay. That would make it easy for the automation to be completely wrong. So, I made sure to only buy switches/relays that had both on and off buttons. Later, I reverse engineered the RF protocol to allow me to generate it directly. Now, I just use Wi-Fi switches with Tasmota or esphome on them. They aren’t really better at the basic function (how hard is on or off really) but do provide a better experience and more data (that I rarely look at).
.
