So, I've made some more discoveries.

The first, and most positive, is that the second and third-to-last bytes in each word are definitely a CRC. I found an implementation of the 16bit CRC-CCITT algorythm which produces matching results to the packets I've recorded. This is good - not only can I more robustly check the received data, but I can write my own packets to transmit.

Next, I tapped into the tx and rx line on the remote between the T6B70BFG and its uc. First, I concentrated on decoding what the T6B70 was receiving (due to the transmission, this also included transmissions from the remote). An esp8266, logic level shifter, and a bit of code saw success (a 5v arduino would also work nicely, of course). 1200 baud is very slow, but allowed receiving characters one at a time, working out the expected message length, message type and received data, and also calculating the crc and checksum and confirming the packet was good.

So now I had access to any data sent by or to the remote. This only included day/time, outside temperature, and power/pump/fan/compressor status (on or off). Useful, but not everything I wanted. To get to the other data, the remote has to request it. I tried sending a request packet from my esp, including the 18ms delay between each byte, and... nothing.

Using my logic analyser, I could confirm that 'my' packet matched the request from the remote exactly, but didn't also appear on the RX line! The esp wasn't pulling the TX line to zero hard enough to overcome the pullup from the remote's uc. Cutting the trace and inserting a 270ohm resistor between uc and esp pins (so the uc had to drive through the resistor, but the esp was driving the T6B70 directly) was more successful, and the esp could now pull the line much closer to 0V (and was being seen on the RX line too), but the remote could still send packets too.

Unfortunately, although I could now transmit the request packets, I ran into the next problem. Any time I tried to transmit 'my' packet, pretending to be the remote, the remote would notice and error out, producing a series of loud beeps. In addition, it would immediately send another packet to the ASHP (presumably announcing its error status) and the ASHP would not send the requested data.

I attempted pretending to be a second remote by setting the 'send' address to 0x02. This didn't upset the remote, and got to the ASHP, but instead of the data I wanted, all I got back was a strange new packet, which I assume was something like 'unauthorised'...

I did try, using my logic analyser, listening the the rx and tx lines as I powered up the system, in the hope that I'd find an 'authentication' or setup conversation. I think I did, but as it consisted of over 200 bytes, the likelyhood of being able to understand enough of it to register as a second remote is unlikely, and even if possible, would probably require crafting correct responses to the ASHP's periodic packets.

This was frustrating. If I manually requested each bit of data using the remote, my code would quite happily read the responses and could pick out the data from each packet. I had hope to keep my work on the remote minimally invasive, but I think if I want to get this data, I will need to 'fake' button presses to get the remote to request the data itself, and just listen to the RX line. This will have the side effects of a beep with each button press (the buzzer can of course be removed, I'll just lose audio indication of errors etc. Perhaps I can hold it silent somehow while I'm 'pressing' buttons), and the remote displaying each bit of data instead of the nicer time/day/status screen. However, as it has a door that shuts, and as I've already built a html5 replacement display...