Hey @Ethan-Cmt,
Those are unknown in analysis so far - Are you monitoring a PAR-WR51R-E or PAR-WR61R-E?
The captures on Github are from my 5xR series, the 6xR series may have something different
@F1p Iām monitoring a PAR-WR61R-E on the shared frame.
It seems that the receiver model is causing this byte to differ, as it correctly goes to 0 when I connect a PAR-WR51R-E.
did you have a 3.3v to 5v level shifter in between?
@gekkekoe Yes, Iām using a voltage divider with 10k and 18k resistors (Vout = 3,21V).
Is there anything that the PAR-WR61R-E can do differently to the PAR-WR51R-E?
@F1p It does exactly the same thing, no additional command. The frames are exactly the same except for this byte for this type of command.
Ah cool, last time @F1p tried we had some issues
@gekkekoe What kind of issues ?
We tried pullup but his adapter was very picky. We we eventually managed to extract most of the data
I was able to tap both sides tx/rx
But i was not able to proxy (Man-in-the-middle) the protocol
ESP32 > PAR-WR51R-E did not accept the lower Tx voltage level generated by the ESP32
I havenāt used a man-in-the-middle attack either. For now, Iāve just been observing the traffic in parallel, but I havenāt yet decided how to send data. I was thinking of using a pull-up resistor, but now Iām starting to have doubts. Do you remember the value you chose?
My 10k pullup on Tx did not work 
I would loke to know if it works with the other board you got 
For now, Iām going to sort through my data and compare my results with yours. Once thatās done, Iāll create a version of my prototype designed for writing. If it works, Iāll let you know and share my schematic if youāre interested 
yes please share your results.
But just for my curiosity, what are you missing with the current implementation ? And why would you prefer CNRF over something line in1/in6 ?
Your work is very thorough and high-quality. However, I had started my tests before discovering your project; I stumbled upon it while decoding the data frames I had captured.
I connected to the CNRF port simply because it was the port used with the compatible thermostat I had found (PAR-WR61R-E/PAR-WT60R-E). What are in1/in6 for?
I am, however, open to suggestions for interfacing with the heat pump, so that I can remotely configure the heating curve and manage the auxiliary heating element.
The most annoying part about CNRF is that is has a resolution of 0.5c. Also the FTC always uses +1c overshoot. When you are using Mitsi AA, then it works okay.
In1/in6 are the dry contacts when connecting a hardware thermostat, they can have a higher temp resolution and overshoot is a bit more friendly.
CNRF wonāt allow you to manage auxiliary directly. Also CN105 has no known option to manipulate the weather curve.
I introduced my own auto adaptive to control the heatpump: esphome-ecodan-hp/docs/auto-adaptive.md at main Ā· gekkekoe/esphome-ecodan-hp Ā· GitHub
@f1p has an advanced weather curve compared to Mitsi
But itās good to get your hands dirty and poke around!
I noticed you hadnāt identified the function of byte 11 in the Reply Initial Settings payload. This is the indoor unitās model family.
Iāll be sure to share my results with you once Iāve finished sorting through my data.
It will take me a few more days.
Is that 0xAC in my capture?
Whatās the translation of different types?