Here's the decoding info for history (input report 3). Much of this was already either known or guessed at. I've confirmed the location of all of the fields on both 2032C and 1035 consoles. As 1035 consoles don't spit corrupt data it should be low risk to add this for all but 2032C consoles.
Input Report 3 is broken into sub-records by the "0xaa, 0x55" separator sequence. There is a separator sequence prior to the first sub-record, but none after the last sub-record. Each sub-record contains a six byte header:
Sub-record Headers
Byte(s) Contents
=======================================
0 Sub-record ID (1-6 are valid)
1,2 Unknown, always seem to be zero
3,4 Size of the sub-record in "chunks"
5 Checksum -- this is the total of bytes 0..4 minus one
A note on the size field: This seems to indicate how many "chunks" follow, but the size of the "chunk" is assumed and depends on the sub-record ID:
ID(s) Chunk size
=======================
1,2,3,5 8 bytes
4 32 bytes
6 meaningless -- ID6 never contains any data but a size of "4" is always declared.
For all but sub-ID 6, the total sub-record size should be equal to (6 + chunk_size x size)
To the best of my knowledge this is what each sub-record contains:
ID Contents
======================================
1,2 These seem to contain 8-byte chunks of historical min/max data.
Each 8-byte chunk appears to contain two data bytes plus a 5-byte time stamp
indicating when the min or max event occurred
3 This time stamp indicates when the most recent history record was stored,
according to the console's clock.
4 History data.
5 This time stamp indicates when the request for history data was received.
6 This only seems to be an end marker indicating that no more data follows in the input report.
Time stamp sub-records (IDs 3,5) contain 8 data bytes as follows.
Byte Contents
=============================================
0,1 for sub-ID 3, the number of history records available when the request was received.
0,1 for sub-ID 5, unknown
2 year - 2000
3 month
4 day
5 hour
6 minute
7 for sub-ID 3, a checksum - sum of bytes 0..6 (do not subtract one)
7 for sub-ID 5, unknown it is just 0xff
12-minute History Records
This applies to the sub-record in Input Report 3 with an ID code of "4". Bytes The first six bytes is the sub-record header and bytes 3,4 contain the number of history records to follow within the sub-record; call this "N". After stripping off the 6-byte record header you should be left with N x 32 bytes. If not then data got corrupted or you had an incomplete transfer.
After removing the header (6 bytes) break the remainder into 32-byte chunks. The description below applies to each 32-byte chunk. I believe that records are sent in most-recent-first order, so the time stamp on sub-record ID 3 applies to the first 32-byte chunk and each following record is another 12 minutes into the past.
Byte(s) Mask Contents
========================================================
0-1 Indoor temp F = (value-1480)/10
2-3 Outdoor temp F = (value-1480)/10
4 so far, always zero.
5 Indoor RH %
6 so far, always zero.
7 Outdoor RH %
8-9 Wind Chill F = (value-1480)/10
10-11 Heat Index F = (value-1480)/10
12-13 Dew Point F = (value-1480)/10
14-15 0x07ff Pressure in mb
16 see below
17 0xf0 always zero so far on all consoles
17 0x0f Current wind direction (decode per the known wind direction map)
18-19 0xffff Current wind speed km/hr = value / 16
20-21 0xffff Peak wind speed in km/hr = value / 16
22-23 0xffff Average wind speed in km/hr = value / 16
24-25 Amount of rain in rain event
26-30 Date/time of rain event, yy,mm,dd,hh,mm (all 0xff if there is no rain event)
31 see below
Notes:
Bytes 4,6 have only been seen to be zero on any console
Byte 16 is always zero on the 2032 console, but seems to be a copy of byte 21 on the 1035 console.
perhaps this is a check byte?
Byte 31 is always zero on the 2032 console, but seems to be a copy of byte 30 on the 1035 console.
could this be another check byte?
Wind speed data from 1035 console contains fractional amounts -- the least significant nibble is
not always zero. The 2032 console only shows integer values for wind speeds.
For only getting at indoor RH, query history every 12 minutes and pluck out byte[5], discarding everything else. The first query may return many history entries (emptying the logger memory) but every 12-minute query after that will only return one history entry.