Security Goals

First off, let's have a look at the security goals for this project:

1. Measurements must be authentic: they must stem from the sensor, and not be manipulated or injected by some other third party
2. Measurement data must be transmitted in a secure way: a third party who is listening to the radio traffic must not be able to conclude what has been measured

Implementation

To fulfill 1) encryption alone is not sufficient - some kind of message authentication code is required. Canique Climat uses an AEAD: Authenticated Encryption with Associated Data.
There are 2 robust AEAD ciphers: AES-GCM and Chacha20-Poly1305. Canique Climat uses the latter one. The message format looks like this:
[Message header] [Encrypted Payload] [Authentication Tag]

The message header provides information about who's sending to whom, and how to decrypt the message. The authentication tag is calculated based on the payload and the message header. To calculate the authentication tag, you need to have the secret key used to encrypt/decrypt the message.
The tag changes whenever the message header or payload changes.
If any bit is incorrect (e.g. transmission error) in the message header or payload or if the authentication tag itself has been manipulated, the authentication tag won't match the message and the receiver of the message will treat the message as a fake message.

When you want to encrypt/decrypt a message with Chacha20-Poly1305, you need 3 things: the key, the message and an IV (96 bit long initialization vector).
The IV must be unique for every single message where the same key is used. This is an absolute security requirement. So it is wise to have some sort of a counter in the IV. Sender and receiver must use exactly the same IV for successful encryption/decryption of the same message - but with every message the IV must change to some IV never used before. The IV itself is not secret. So you can transmit it or parts of it (like the counter).

Canique Climat transmits parts of the message counter in the message header. The receiver reconstructs the full IV from that counter. It is important to note here that when building the authentication tag the full IV needs to be authenticated.

So by using Chacha20-Poly1305 we can make sure that both our requirements 1) and 2) are fulfilled.

Replay attacks

Now imagine the following scenario: Your authentic device transmits the value -18.59°C at 15:00. 2 hours later an attacker retransmits the very same message, bit for bit. This is called a replay attack.
Some valid transmission recorded beforehand is replayed by a third party. The real temperature might have rosen to -12.00°C but your receiver is thinking the temperature is still -18.59°C.
The same scenario works for door status - Canique Climat can also be used as a reed sensor by the way. By using a replay attack you could fool a receiver into thinking the door is still closed/open or has just changed its state.
Canique Climat has a countermeasure against this kind of attack. It's a counter in fact. The message counter used for the IV is also used for replay attack prevention. If the receiver receives a message with a message counter that he has already received and successfully decrypted, the next message that the receiver will accept will be one with a higher message counter. The latest/highest message counter is stored and compared to the currently received one.

Hardware Cryptography in RFM69

Now let's compare Canique Climat's rather sophisticated software based approach to the hardware AES engine in the RFM69 (SX1231 transceiver)
RFM69 is said to be using AES-ECB mode - see https://forum.pjrc.com/threads/27442-interrupt-automode-driven-library-for-the-RFM69.

Quoted from that forum:
I checked the cipher mode used in the radio module, (I couldn't find it in the datasheet), the AES cipher mode turned out to be ECB unfortunately (check_crypto_mode.py). Also, as required with a block cipher, data is zero padded to multiples of the blocksize (16 bytes) so you lose the performance benefit of transmitting short messages

So RFM69 modules have a negative effect on message size, if hardware AES is used, plus their hardware AES is insecure.
AES-ECB mode in a nutshell: given a key k, the same plaintext message leads to the same encrypted output.
Just 1 example:  plain text "DOOR OPEN" => encrypted "xr2BRKm3z"
Now even if you can't decrypt the message, you know that every time this encrypted message is transmitted, the door is in state A/B. If you can e.g. see the door from outside just one single time, you can then tell based on the message whether the door is open or not - forever. You can conclude from the message content in which state the door is.
With Chacha20-Poly1305 you don't have this problem. Every encrypted message, even if the plaintext stays the same, is different - because the IV is different.
To put it short, the AES engine of the RFM69 neither fulfills requirement 1) nor 2).

Coming soon: Firmware Updates