Community
OpenEnergyMonitor

Community

Daikin S21 internals

Tags: #<Tag:0x00007f6e08e2db00>

Hi everyone,
some news regarding Daikin WIFI interface - well more like the S21 port… basically continuing my post in Hack my Heat Pump and publish data onto emoncms (apparently I can’t post more than 3 replies to the same topic…). If this is a wrong category for such discussions, please correct me.
I connected new BRP069B41 wifi adapter to my FTXB-C (via KRP067A41E splitter), and connected uart sniffers to both RX and TX lines. I got advice from @hui5368 to use 2400,8E2 settings… so I sniffed the communication using that.
It seems the communication on S21 really is a serial port, I can see a request/response type of messages. Wifi adapter is sending requests all the time and Daikin is responding. Packets are binary, from preliminary analysis this is what it looks like:
Wifi: 02::::03
Daikin: 06 (ack?)
Daikin: 02:::[]::03
Wifi: 06 (ack?)
is always <request-type+1> (until now all the request-types are even and response-types odd, so it may be the lowest bit indicates packet direction?)
is always the same in request and response.
have fixed length for each request/data type, but can vary for different types and there is no indication of length in the packet, which means the length is probably fixed for each type.
are lowest 8bits of a simple sum of all the bytes except leading 02 and trailing 03.
I did not try any advanced requests to Wifi yet, just get_model_info, get_control_info and get_sensor_info - none of them triggered any different behaviour on the S21 directly, so I suppose data for those requests is gathered in wifi module in the background, and responses simply contain latest values. My Daikin unit was turned off the whole time.
Wifi module repeats following request packets continually:
02:46:32:78:03 (this is the one sent twice per second without Daikin connection, so it must be some basic connection detect, or model info request)
02:46:31:77:03
02:46:33:79:03
02:46:34:7a:03
02:46:35:7b:03
02:46:38:7e:03
Daikin responses for them are also the same all the time so far:
02:47:31:30:30:4e:41:67:03
02:47:32:34:3a:00:00:e7:03
02:47:33:30:fe:fe:30:d6:03
02:47:34:30:00:80:00:2b:03
02:47:35:30:30:30:80:8c:03
02:47:38:30:00:00:00:af:03
I have no idea what these values mean so far…
More interesting are request-types 52, sent about every 12 seconds:
02:52:48:9a:03
02:52:49:9b:03
02:52:4c:9e:03
02:52:4e:a0:03
02:52:58:aa:03
02:52:61:b3:03
02:52:64:b6:03
Responses I have seen so far for them:
02:53:48:30:36:32:2b:5e:03
02:53:48:30:37:32:2b:5f:03
02:53:48:35:36:32:2b:63:03
02:53:49:30:37:32:2b:60:03
02:53:49:35:36:32:2b:64:03
02:53:49:35:37:32:2b:65:03
02:53:4c:30:30:30:2f:03
02:53:4e:36:33:31:2b:66:03
02:53:58:30:35:32:2b:6d:03
02:53:61:30:36:31:2b:76:03
02:53:64:30:30:30:47:03
The changes in 53:48 correspond to observed change in internal temperature (htemp value in get_sensor_info HTTP response), value went from 27.0 to 26.5 and then 26.0, so the data bytes here are probably invert-order ascii-encoded value with fixed decimal point (30:37:32 -> 32:37:30 -> 270). Values in 53:49 seem to be tracking them - they are usually same or .5dC higher. Perhaps some kind of internal device temperature? 53:4c, 53:4e and 53:64 are unknown so far. 53:58 might be the set point, which I have at 25.0 now. 53:61 might be outside temperature (my own outside thermometers reported 16.3-16.5 through all the monitored period, so 160 may mean 16.0?)
Next steps:

  1. try turning the unit on, eventually changing some settings and see how it impacts the packets
  2. connect uart directly to daikin with these settings (2400,8E2) and emulate the wifi module requests - see if daikin responds. Eventually try different settings at 2400baud if the unit won’t react.

A post was merged into an existing topic: Hack my Heat Pump and publish data onto emoncms