Hack my Heat Pump and publish data onto emoncms

Hello everyone,
just a status update, in case anyone’s still interested in S21…
@gyrex: S21 is for sure not compatible with RS485 if that is what you asked.
S21 pinout is very simple: 1:+5V, 2:Tx, 3: Rx, 4: +12V, 5: GND
S403 pinout: 1:+15V (power for wireless modules), 2: JEM-A OUT (pull-down=ON), 3: JEM-A IN (pull-down=toggle switch), 4:Tx, 5: Rx, 6:GND, 7:GND, 8,9:NC, 10: ~327VDC
Now, S403 is split by adapters like KRP067A41E into 4pin JEM-A connector and 5pin S21, using optoisolators on Rx,Tx,J-in,J-out. I can post detailed pinouts of all adapter connectors if anyone is interested, but generally these boards are not required as far as I can tell.
I have successfully connected BRP069B41 wireless module directly to S403, using pins 1,4,5,6 (wifi module does not use 5V on S21:1 at all).
I have also managed to connect arduino to JEM-A directly on S403 - pin 2 with 10K pull-up detects if aircon is on or off (1=off,0=on) and pin 3 can switch current status by shortly pulling it to ground (S403 has it on 5V by default).
The Rx/Tx are pretty much equivalent on S403 and S21, the adapters just add optoisolation. It’s definitely full-duplex data link with a 5V pull-up, but I have no idea what protocol is used there. For a moment I hoped it could be uart, because BRP069B41 (not connected to aircon unit) kept sending same short burst every 0.5s which looked almost like 5 bytes with checksum on 2400baud serial (data 02h,46h,32h,78h,03h), which looked like ,payload,,<??>, but replaying the same bytes on 2400,8N1 and 8E1 uart straight to S403 got no response from the aircon unit. Connecting wifi module there did get a response and fully successful connection however.
I cannot say for sure it’s not a normal 5v uart - the pins are connected to pins 28 (TxD1) and 29 (RxD1) of M30280 MCU which would hint at uart, although both pins can also be used as standard GPIO pins.
Basic oscilloscope probes showed slight timing differences in the wifi output vs. normaln 2400baud uart sending the same data, so it might all just a strange coincidence with payload-lenght and checksum, or it may be that my usb/uart converter did not sufficiently match some other electrical or timing requirements of the aircon MCU.
I have already ordered another wifi module for the same type of unit (FTXB-C, which according to all the specs should not be compatible with them, but we all know how the public documents work…), I plan to do additional tests there with S403/S21 adapter in place, and eventually also hooking logic analyzer probes to both Tx and Rx to captute full communication between wifi and MCU, but that may take another month or two.
Meanwhile I have connected the wifi unit to mobile app and verified it works fine, all the sensors and control work, even wifi-module firmware upgrade went fine. Communication seems to match the HTTP protocol documented here for example (GitHub - ael-code/daikin-control: Unofficial api documentation and web interface to control "Daikin Emura" air conditioner), at least some subset of it (get_timer returns 404 not found for example but that might be because FTXB-C does not support that functionality).
Another thing I plan to do when new module arrives is retrieving full content of the SPI flash chip, which may be possible to reverse-engineer for more internal info, although for sure not trivial. Fetching firmware code from aircon unit seems unlikely, as the code is on the MCU chip, which I could not even exactly identify. It’s a TQFP80 with markings “M30280DKFA”, which makes renesas M30280FAxx most compatible (96k flash, 4k ram), but I have not found any mention of “DK” anywhere so it may just as well be something specifically manufactured for Daikin, thus invalidating any MCU internals found in official datasheets.
Another thing I’ve noticed (and used for oscilloscope probing) is the 3+4pin S24 connector on the main control PCB, which has among others also the Rx and Tx signals routed (top left):


It looks like some kind of debug interface, might be worth to trace all the pins to MCU or power, and do some oscilloscope probes there.
Uff… if anyone read through all of this ranting and has some ideas, let me know :wink: