So, more captures, and some decoding later...
When the system is sat idle, there is a periodic 'conversation' that takes place between the ASHP and the remote, starting each ~5 secs by the ASHP sending a packet, which is acknowledged by the remote, followed by some data from the remote, acknowledged by the ASHP:
-> 07 00 01 08 00 00 EF <- 05 01 00 09 F0 <- 0E 01 00 97 08 0E 10 05 01 00 32 7B FE 82 -> 05 00 04 08 EE -> 07 00 01 08 00 00 EF <- 05 01 00 09 F0 <- 12 01 00 A1 00 16 00 00 00 00 00 00 00 00 00 33 26 DC -> 05 00 04 08 EE -> 07 00 01 08 00 00 EF <- 05 01 00 09 F0 <- 0B 01 00 A3 A4 00 00 00 A4 47 C1 -> 05 00 04 08 EE -> 07 00 01 08 00 00 EF <- 05 01 00 09 F0 -> 05 00 04 08 EE
Also, on the stroke (or shortly after, if there is an ongoing transmission) of each minute, the remote sends:
0E 01 00 97 20 09 00 06 01 00 32 D1 62 C4
Other messages are also sent, but only on status changes - only the above are sent periodically.
There are several 'types' of packet.
The first byte is always the packet length (total, in bytes)
The second byte is either the sending station ID, or receiving, with the third byte (usually) the other. Packets from the remote are always 01 00, and from the heatpump 00 01 (apart from the 05 00 04 08 EE acknowledgement packet).
The 4th byte is perhaps the packet 'type'.
The last byte is a sum compliment checksum.
I have observed the following 'type' bytes:
- 0x08 - 'OK' status from the ASHP?
- 0x09 - Ack from the remote?
- 0x97 - Day/Time and power from the remote
- 0x98 - Day/Time and power back from the ASHP
- 0x99 - Request from the remote for specific data
- 0x9A - From the ASHP, contains various data
- 0x9C - From the ASHP, contains the outside air temp and pump, fan and compressor status
- 0xA1 - Unknown, but from the remote
- 0xA3 - Also unknown from the remote, but the 5th byte appears to increment periodically
0x08
This is seen as part of either 07 00 01 08 00 00 EF packet (requesting data from the remote?) or 05 00 04 08 EE (acknowledgement?) from the ASHP. Nothing interesting.
0x09
Only ever appears as a response (05 01 00 09 F0) from the remote to 07 00 01 08 00 00 EF from the ASHP. Again, nothing interesting here.
0x97
This one contains some data.
- 5th byte - minute
- 6th byte - hour
- 7th byte - second
- 8th byte - day
- 9th and 10th bytes - 00 00 means the ASHP is on stand-by, 01 00 is on, but no DHW or CH demand, 01 01 is on with DHW demand, and 05 00 is on with CH demand.
The remote sends day/time and stand-by/on data to the ASHP, and the ASHP sends the demand data.
0x98
This is sent by the ASHP back to the remote as an acknowledgement, and contains the same data.
0x99
Request from the remote for specific data from the ASHP.
- 6th byte - the requested data, plus 0x64
Once this is sent, the ASHP will respond with 0x9A and 0x9C packets until the remote sends another request (I still need to find what it sends to stop requesting at all...)
0x9A
Data from the ASHP, usually in response to 0x99 packets, but also sent semi-periodically during DHW and CH demands.
- 6th byte - the requested data, as above. Set to 0x67 (power consumption, watts) during DHW and CH demands
- 8th byte - the value
0x9C
Data from the ASHP, appears to be sent occasionally and also in response to requests - perhaps just sends when a parameter updates.
- 7th byte - Outdoor air temperature, multiplied by two, to allow 0.5degC resolution
- 9th byte - water pump, compressor and fan status. 0x00 is all off, 0x20 is pump running, 0x70 is pump, fan and compressor running, 0xA0 is fan off, compressor on over-run and pump running. (I've not yet identified which bit is the fan and which is the compressor as both turn on and off at the same time - this may need some crafted packets to be sent to the remote to know for sure)
0xA1
Sent by the remote periodically in response to the ASHP's 07 00 01 08 00 00 EF. Unknown, but must contain some data as some bytes change. (6th, 8th, 9th at least)
0xA3
Also sent by the remote periodically as above. Also unknown, but the 5th byte appears to increment, although I've not yet determined the trigger.
So, plenty of gaps still, but I should now have enough to listen in to most of the data I want, and send requests for the rest! The logic levels inside the remote are 5V, so I need to find (or likely quicker, wait for a new one in the post...) a logic level converter to interface with an ESP for monitoring over wifi.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.