Nest Hacking

Info

• /dev/event1 is the knob; /dev/event2 is the button

Nest software

/nestlabs/sbin/nlclient -config /nestlabs/etc/client.config -config /nestlabs/etc/Display/Display-2/client.config

Nest backplate interface

• Connected on /dev/ttyO2
• All communications with backplane begin with (d5)d5aa96 (d5 is doubled only for data FROM backplane)
• 16-bit command
• 16-bit data length
• 16-bit checksum

Monitor:

strace -ff -p $(pidof nlclient) -x -s9999 -e read,write 2>&1 | grep '(54'

Checksum

<Bytes-from-end>.<bit-value> <xor-with>

00.01  2110 (1021)
00.02  4220 (2042: 1021<<1)
00.04  8440 (4084: 2048<<1)
00.08  0881 (8108: 4084<<1)
00.10  3112 (1231: 8108<<1^1021)
00.20  6224 (2462: 1231<<1)
00.40  c448 (48c4: 2462<<1)
00.80  8891 (9188: 48c4<<1)
01.01  3133 (3313: 9188<<1^1021)
01.02  6266
01.04  c4cc
01.08  a989
01.10  7303
01.20  e606
01.40  cc0d
01.80  981b
02.01  3037
02.02  606e
...
03.01  b476
03.02  68ed
03.04  f1ca
03.08  c385
03.10  a71b
03.20  4e37
03.40  9c6e
03.80  38dd
...
07.20  687b

If you compute the contribution of the individual bit changes in the data you end up with the xor table above; byte offset from the end of the data, bit pattern, xor value. Correcting for little endianess in the output you end up with the hex values in parenthesis. The least significant bit is 0x1021 and each subsequent bit is a shift left, if the XOR value has the 0x8000 bit set then it is XORed with 0x1021. This is the CRC-CCITT polynomial.

 8  7  6  5  4  3  2  1  0
d5 aa 96 82 00 02 00 00 00: 08b2
         ||     |
         ||     68ed
         |408b
         20d4
 
08b2: 68ed ^ 408b ^ 20d4

Starting at the least significant bit and filling in the XOR values for each bit gives the above diagram; the diagram stops at the 20d4 XOR value because at that point it matches the final CRC. This tells us that the CRC covers the 6 bytes prior.

#!/usr/bin/env perl
use Digest::CRC qw(crc);
my $data = pack("H*", "820002000000");
printf("%04x\n", crc($data,16,0,0,0,0x1021,0,0));

We can also compute the same CRC in Perl; note the result will be byte swapped since the data encodes the number as little endian.

FET control

Turn on  W1: d5aa96 8200 0200 00 01 29a2
Turn off W1: d5aa96 8200 0200 00 00 08b2
Turn on  Y1: d5aa96 8200 0200 01 01 1891
Turn off Y1: d5aa96 8200 0200 01 00 3981
Turn on  G : d5aa96 8200 0200 02 01 4bc4
Turn off G : d5aa96 8200 0200 02 00 6ad4
Turn on  OB: d5aa96 8200 0200 03 01 7af7
Turn off OB: d5aa96 8200 0200 03 00 5be7
Turn on  W2: d5aa96 8200 0200 04 01 ed6e
Turn off W2: d5aa96 8200 0200 04 00 cc7e
Turn on  Y2: d5aa96 8200 0200 07 01 be3b
Turn off Y2: d5aa96 8200 0200 07 00 9f2b
Turn on  * : d5aa96 8200 0200 0b 01 d37e
Turn off * : d5aa96 8200 0200 0b 00 f26e

FET presence

The backplate will, at least upon connection, send information about which FETs have a wire present. This data is received with command ids 0004, 0009, and 008f, in that order. Each sensor is represented by one byte which is either 00 (not present) or 01 (present).

The content of 0004 and 008f appears to be identically formatted: W1, Y1, G, OB, W2, ?0, ?0, Y2, ?1, ?1, ?0, *, ?0

The content of 0009 is arranged differently and has 2 more values: W1, Y1, ?1, ?1, ?0, G, OB, W2, ?0, Y2, ?0, *, ?0, ?0, ?0

Run BeagleBone/Debian programs

ln -s . /lib/arm-linux-gnueabihf
ln -s ld-2.11.1.so /lib/ld-linux-armhf.so.3