Interior and reverse engineering of the Ariston Velis 80 Wi-Fi electric water heater on ESP32 (part1

.
What is it that a boiler with a Wi-Fi module inside offers? How is it built, what does the app offer? Can its firmware be changed? I invite you to the first part of the adventure with the Ariston Velis 80 and the Ariston NET app - today we will start with the purchase, the unpacking, the app test and present the tiles from inside. Then we'll start working on the analysis of the communication protocol.... we'll see how much we can do.
.
Let's start with the purchase. The hardware was bought home by our forum mate @DeDaMrAz , who is simultaneously developing with me our open source firmware electrodes for IoT devices. I got all the images from a colleague and we developed the theme together.
The device cost €322, but it was bought where my colleague lives, i.e. in Serbia - the price in Poland may vary.
.
The package arrived quite quickly, the courier brought such a box:
.
The whole thing is well packed for transport. In the box we have a full pictorial manual and a detailed multilingual manual. There is also a leaflet declaring the energy class B of the product.
.
The manual is also available online. It specifies parameters such as (for the 80 version) a weight of 27 kg, a capacity of 65 litres, a noise level of 15 dB and a declared energy consumption per week of approximately 27 kWh in smart mode and 35 kWh in standard mode.
.

Ariston NET App .
On the packaging you will find a QR code leading you to the shop of your choice - Google Play or Apple Appstore:
.
Pairing is very simple, we simply put the device into pairing mode following the instructions after registering with the app.
.
We then get access to the boiler panel, where we can edit its programme and schedule, create automation, view the current and target temperatures, check the time left to heat up and the estimated number of 'showers' its condition will allow:
.
An interesting feature is the ECO option - this is based on an analysis of the user's previous habits. At first, this function "learns" for a week how we use the boiler and then adapts the heating to our habits. The aim is to reduce energy consumption and reduce heating when it is not needed.
.
The learning process continues and reaches its greatest efficiency after a few weeks. At the same time, the algorithm makes sure that even in an unexpected situation the boiler has a minimum of usable hot water.
.
The boiler also has functions such as antifreeze, which is automatic protection against water freezing inside the unit by activating the heater when the temperature drops below 5 °C, and anti-legionella, which is a thermal disinfection cycle that heats the water to 60 °C per hour to eliminate Legionella bacteria.

Interior of the appliance .
Time to start dismantling. What does such a device control?


Electronics on the table during testing:
.
The main panel has a 7-segment two-digit display, a Wi-Fi module with ESP32, and an additional microcontroller.
.
Separately, we have a power supply with relay. The power supply is based on the LNK623DG. The designation is 740190023201 TFE-RL. Interestingly, there are even interference filters and a varistor inside already. However, this is not the cheapest product from China.
.
Let's focus on the Wi-Fi module. Here we have the ESP32-WATG-32D:
.
Leads:
I36. . . . . . . . . . Ibr/>. U0RXD.

Name	No.	Type		Function
RESET	1		I	Module enable signal (Internal pull-up by default). Active high.
I36	2	I	GPIO36, ADC1_CH0, RTC_GPIO0
I37	7e3	I	GPIO37, ADC1_CH1, RTC_GPIO1
I38	4	I	GPIO38, ADC1_CH2, RTC_GPIO2
I39	5	I	GPIO39, ADC1_CH3, RTC_GPIO3
I34	6	I	GPIO34, ADC1_CH6, RTC_GPIO4
I35	. 7	I	GPIO35, ADC1_CH7, RTC_GPIO5
IO32	8	I/O	GPIO32, XTAL_32K_P (32.768 kHz crystal oscillator input), ADC1_CH4, TOUCH9, RTC_GPIO9
IO33	9	I/O	GPIO33, XTAL_32K_N (32.768 kHz crystal oscillator output), ADC1_CH5, TOUCH8, RTC_GPIO8
IO25	10	I/O	GPIO25, DAC_1, ADC2_CH8, RTC_GPIO6
I2C_SDA	11	I/O	GPIO26, I2C_SDA
I2C_SCL	12	I	GPIO27, I2C_SCL
TMS	13	I/O	GPIO14, MTMS
	TDI	14	I/O	GPIO12, MTDI
	+5V	15	PI	5 V power supply input
GND	16,17	PI	Ground
VIN	18	I/O	12 V / 24 V power supply input
TCK	TCK	19		I/O	GPIO13, MTCK
	TDO	20	I/O	GPIO15, MTDO
	EBUS2		<br/2121,35	I/O	GPIO19/GPIO22, EBUS2
	IO2		I/O	GPIO2, ADC2_CH2, TOUCH2, RTC_GPIO12, HSPIWP, HS2_DATA0
IO0_FLASH	23	I/O	Download Boot: 0 SPI Boot: 1 (Default).
IO4	24	I/O	GPIO4, ADC2_CH0, TOUCH0, RTC_GPIO10, HSPIHD, HS2_DATA1
IO16	25	I/O	GPIO16, HS1_DATA4
5V_UART1_TXD	26	O	GPIO23, 5V UART Data Transmit
5V_UART1_RXD	27	2. 27	I	GPIO18, 5V UART Data Receive
IO17	28		-.	GPIO17, HS1_DATA5
IO5	29	I/O	GPIO5, VSPICS0, HS1_DATA6
U0TXD	30	I/O	GPIO1, U0TXD
U0RXD	31	I/O	GPIO3, U0RXD
	IO21	32	I/O	GPIO21, VSPIHD
GND	<br/33	PI	EPAD, Ground
+3.3V	34	PO	3.3V power supply output

.
.
We soldered it out using flux and hot air.
.
We also looked under the screen to get to the Flash memory:
.
Next to the ESP is the Flash memory with SPI interface - FM25Q64A13, which is 64M-BIT. Divided by 8 gives us 8Mb.
.
Copy of the batch (before pairing) made with esptool.py: https://github.com/openshwprojects/FlashDumps/commit/5e772e8573257f2cd69224823297cade7d9a13ba

Communication protocol analysis .
For testing, we used a USB to UART converter and a logic state analyser. I have presented it before:
Reverse engineering an unknown I2C protocol with the Sigrok analyser using an LED controller as an example .
The board connected for testing:

Boot log from ESP32:
.
Not a lot of information here, although you can trace the SDK used and read the compile time with this.
Pairing log:
.
This log was received on OTXD pin 31 at baud 115200. In addition we also have a UART to talk to the MCU, 5V_UART at 9600 baud.
.
It's probably this main MCU that controls the heating, and the module from ESP32 just communicates with it. As if we knew this protocol, it would only be possible to change the ESP32 batch and so control the whole thing.
We also collected samples there:
.
The same can be previewed in Pulse View. Let's connect our analyser:
.
First we capture the signals:
.
You can see groups of transactions here, let's zoom in:
.
You can also see the individual bits:
.
Then we add the UART decoder:
.
The UART decoder allows us to easily apply bytes to the waveforms. We can then also see the transactions taking place.
.
But in fact, even without Saleae you can quickly distinguish the frames. This can be seen from the repeated packet headers:
.
Frames written in this way also immediately allow us to look up the length of the packet - this is the fourth byte. This is not hidden in any way (for example - there is no XOR with a constant or packet ID). Count it yourself - it fits. For example, a packet with 0x02 argument still has two bytes after 0x02, and probably at the end.... CRC. The checksum is generally at the end.
This situation is also interesting:
.
Here you can see that something is growing and the checksum is growing with it. You can try to derive this sum. 0x45 has increased by 1 and the control sum has also increased by one.... so it's probably the sum modulo 256, a quick check confirms:
.
This can now be verified. PulseView allows you to write plugins, and plugins can be based on other plugins - so for example Modbus is based on UART. Documentation:
http://sigrok.org/wiki/Protocol_decoder_HOWTO
I have therefore prepared a CRC checking plugin:
.
After checking, I put the result under the decoded packet. This allows me to quickly check all communication. These plugins are really very convenient.
.
However, something went wrong. It seems that half of the packets have one byte in front, which is skipped in the CRC.
.
Corrected:
.
Much better:
.
You can go one step further and verify the length as well. This will allow us to quickly check that I have correctly understood the meaning of the box in the frame. I compare the length from the frame field with the actual length of the frame (reduced by the header and CRC):
.
Similarly, packet type information can be issued:
.
I have also added a display of the data carried by the package:
.
Now you can move on to the next step. Consider this excerpt:
.
It looks like packet 0x25 could be a kind of value reading.
Here we have:
- a query of what is at address 11 23
- answer that 00 00 01 00
- a query about address 44 24
- reply, DC 05 C8 00 B8 0B DC 05
- request for address 45 24
- answer DC 05 00 00 B8 0B E8 03
- request for address 46 24
- reply 64 00 32 00 B8 0B 64 00
- request for address 47 24
- reply 0A 00 01 00 64 00 0A 00
Then packets 0x25 end and 0x23 begin:
.
Let's go back to 0x23. It looks like the addresses are consecutive - 0x4424, 0x4524, 0x4624. In that case, one could bet that the first is a less significant byte, and in practice we have here 0x2444, 0x2445, etc.
This excerpt also confirms this - 00 00 01 00 - this is simply 1.
Then what do we have here?
DC 05 C8 00 B8 0B DC 05 .
DC 05 -> 05DC -> 1500
C8 00 -> 00C8 -> 200
B8 0B -> 0BB8 -> 3000
DC 05 -> 05DC -> 1500
I wonder what the values are - hours? But that may come later.

It's now still the 0x23 package:
.
Z - query, O - answer.
Z: 60 10 68 13 69 13 6A 13 6B 13 43 51
O: 24 01 23 01 26 01 23 01 25 01 FF FF
Z: D3 4B C4 4B D9 46 5E 47 CB 4B CC 4B
O: 00 00 00 00 00 1B 00
Z: 4F 9D 50 9D 4C 9E 4D 9E 57 D1 4A D8
O: C9 00 00 00 00 00 00 00 00 00 00
Next:
Z: D0 3D D2 3D C4 3E
O: 00 00 00
At this point I'm puzzled by the change in response length with the same query length. I thought these were setting records, but it's hard to tell at this point.

Full PulseView plugin code for review .
This should be placed in C:Program Files (x86)PulseView as pd.py with the appropriate call from init. If in doubt, just look at other decoders, e.g. Modbus.
.

Further plans .
For the second part of the topic:
- collect more data
- start comparing data from the packages with that from the application
- try to collect data when the boiler is switched on and off, compare, find what turns it on/off
- similarly for different temperatures
- upload your own batch to the ESP and try to send something
- or upload the batch from the ESP to our ESP and try to imitate the boiler with our own program

Summary .
Decoding the protocol is not complete, but the topic got quite long, so I will split it into two parts.
Does anyone know more what this protocol might be? .
Ultimately we would like to run this boiler with its own firmware and control it from Home Assistant. The number of packets is quite large, but you may not need to handle all of them to gain control of the temperature.
I attach the captured data. You can download PulseView, add my plugin there and view the frames. Ideas?