py-spirit1

I published the code I've been writing to github after refactoring it slightly to make it simpler to use and easier to expand from. There is still a lot missing but it's working for me and and as I delve further I will try and keep it up to date. If anyone can improve on it, let me know! Pull requests are always welcome :-)

You can find it at https://github.com/zathras777/py-spirit1

Patterns?

Now that I have a more reliable and consistent packet grabber, I have been trying to find any patterns in the output. I assume each message will have some form of header followed by a body. There may also be a CRC and it could be that the builtin AES encoder/decoder is used for the payload?

The RF controllers are powered by batteries and seem to exhibit fantastic battery life, so I assume they have very little interaction with the heaters unless I press a button. As the heaters are mains powered I assume they have no such low power requirements and hence send out regular packets. This appears to be the case from what I have observed. The messages I have used for this post are all from these regular transmissions.

I considered that these regular packets could have been noise or generated from something else in the house, but they have the correct preamble and sync words which makes this unlikely.

Time & Size?

This output shows the time 16 packets were received with their sizes.

$ python3 ./example.py 16
Trying to receive 16 messages.
22:46:36 DEBUG receiver - receive: messsage of 40 bytes
22:46:54 DEBUG receiver - receive: messsage of 72 bytes
22:47:16 DEBUG receiver - receive: messsage of 40 bytes
22:47:34 DEBUG receiver - receive: messsage of 40 bytes
22:47:34 DEBUG receiver - receive: messsage of 72 bytes
22:47:55 DEBUG receiver - receive: messsage of 40 bytes
22:48:13 DEBUG receiver - receive: messsage of 40 bytes
22:48:14 DEBUG receiver - receive: messsage of 72 bytes
22:48:19 DEBUG receiver - receive: messsage of 72 bytes
22:48:35 DEBUG receiver - receive: messsage of 40 bytes
22:48:54 DEBUG receiver - receive: messsage of 72 bytes
22:49:15 DEBUG receiver - receive: messsage of 40 bytes
22:49:33 DEBUG receiver - receive: messsage of 40 bytes
22:49:34 DEBUG receiver - receive: messsage of 72 bytes
22:49:55 DEBUG receiver - receive: messsage of 40 bytes
22:50:14 DEBUG receiver - receive: messsage of 72 bytes

There are 2 different sizes, 40 bytes or 72 bytes which is a consistent pattern I have been seeing. What is the time between packets?

• 72 byte packets - 40 seconds, 40 seconds, 5 seconds, 35 seconds, 40 seconds, 40 seconds
• 40 bytes - 40 seconds, 18 seconds, 21 seconds, 18 seconds, 22 seconds, 40 seconds, 22 seconds

40 seconds seems to be a common theme :-)

Payload?

Every single packet starts with the same 3 bytes: 0xa7 0x46 0x99.

The next 4 bytes are one of

• 0x77 0x46 0x9d 0x0d
• 0x73 0xc6 0x80 0x95
• 0x71 0xc3 0x9a 0x97

After 4 bytes of more variable content we have a block of 4 identical bytes

• 0x8a 0x1b 0xf9 0xca.

Packets with the 0x73 byte in position 3 are 72 bytes long, the others are 40 bytes.

0                    7                    14
--------------------------------------------
A7 46 99 77 46 9d 0d ?? ?? ?? ?? 8A 1B F9 CA
A7 46 99 73 c6 80 95 ?? ?? ?? ?? 8A 1B F9 CA
A7 46 99 71 c3 9a 97 ?? ?? ?? ?? 8A 1B F9 CA

The final portion of the 0x77 payloads shows the variations,

15                      23                      31                      39
--------------------------------------------------------------------------
fa 66 d7 4c 3a 9e f3 ec ee d8 2b e9 84 0e 0e d1 dd 2a 23 5f 50 2a 4d bf a2
fa 76 c7 34 5a 51 ea 2e fe a2 7d e0 22 31 85 6f 1d ac 82 bd da 67 33 11 80
b4 76 9f 3c 19 4e 9c 0f 29 3b f8 a2 9d 2c aa 0d ce 22 5f cf 68 c5 81 8f 93
ea 7e f7 6c 3f 84 a4 30 75 a6 9d 89 73 24 0b 43 5e be fc f0 c2 b7 f0 9c d6
b4 76 9f 3c 19 4e 9c 0f 29 3a f8 a2 9d 2c aa 0d ce 22 5f cf 68 c5 81 8f 93
fa 6e 8f 6c 1f 3f a9 94 50 6f be 31 92 15 7d 3b 6a 20 33 f8 bd fa 7a 54 4e

AES?

Could the payload be AES encoded? If it was I would expect the size of be divisible by 16. If we assumed that there was an 8 byte header then each packet fits neatly within the sizes,

• 8 + 2 * 16 = 40
• 8 + 4 * 16 = 72

However, if it was an AES encoded block I wouldn't expect to see the repeated 4 byte block starting at byte 11? For this reason I'm assuming that AES isn't being used.