@evb Hello. I am the maker of the Canique MK2 boards. I started just like you with the website from Andreas Rohner, desoldering the LED and desoldering the voltage regulator from such a chinese board until I realized this is the wrong way round.
As far as I recall, I've seen voltage regulators consume something in the order of 100uA when reverse powered. So that might be a hint.
The external crystal should not be drawing that much current. Using a 16MHz oscillator current can go as low as 4uA with watchdog enabled - in theory and on boards built with minimum consumption as a design goal.

To your question regarding the SCK pin: yes, if it is connected to a LED every clock pulse on the SCK pin (when SPI is enabled) will make the LED draw current.

You also have these kinds of troubles (SPI drawing too much current when active or inactive) with chinese boards having a BME280 on them for example. If you have high quality standards, the stock chinese boards won't fit your needs.

Here I am introducing part of my project that I've been working on for the last couple of years (since 2016/2017).

Meet the temperature/humidity sensor (picture showing a prerelease state - the sensor will be upgraded soon):

• +5 years battery lifetime (single AA alkaline battery) when sending every 30 seconds. (calculations rather suggest 7.5 years) Everything is highly optimized for low consumption. Almost no public library is used (most libraries don't offer superior quality).

• 400-800m range using 868 MHz carrier frequency

• <2 ppm RTC @ room temperature. Algorithmic temperature compensation is done to reduce RTC offset.

Meet the heat control system supporting Vaillant 7-8-9 interface (again a prelease version):

LEDs and button on the back are hidden in the picture.
The device is able to control the water temperature in Vaillant boilers (and other manufacturers using the same interface). It isn't just using on/off switching. It sets the water temperature between 30°C and 90°C.

• 5-28V input voltage
• output range 3V-24V
• ~6mV output resolution
• Automatic calibration to heating system voltage
• Automatic detection of stable or oscillating voltage at startup
• Many error checks to detect unconnected wire and the like
• Radio: 868 MHz
• Automatic off state when no radio message is received for 5 minutes
• expected power consumption in operating mode < 0.1W
• expected power consumption in standby mode < 0.05W
• button to switch between modes - device can be "disconnected" from heating system by pressing the button (gives control back to the heating system)

The 3rd part of the whole story is the gateway. There is no picture of the gateway yet. It's a complete mini-computer though (no ESPxxx and the like), offering ethernet and an MQTT API.
It's equipped with 4 cpu cores, 512MB RAM, and an external 868MHz antenna.

@Puneit-Thukral You're mixing up the sensor node and the Vaillant heat control system. The minimum input voltage is 5V for the heat control system (only). This has nothing to do with the used MCU, but the 7-8-9 Vaillant interface usually works with 24V. So usually the input voltage is 24V anyway.
The interface for the Vaillant heat system is usually as follows:
24V input => roughly 11V to 17V output on the CTL pin to regulate the boiler temperature
If you used 5V on the input you'd only be able to regulate up to max. 5V.
The Vaillant heat control system (it's the second picture, the one with the box) does not run from batteries. It gets power directly from the Vaillant (or compatible) heating system.

The single AA battery temperature/humidity node runs from a single 0.8V-1.6V battery. You can see the battery in the picture - in this case it's an Eneloop although I'd recommend Alkaline batteries for devices that run for years. To run from a single battery the node has a boost circuit integrated that boosts the voltage to 1.85V.
On all devices (sensor nodes, heating control, gateway) I'm using a variant of ARM Cortex M0+ or Cortex M0. (Eventually it will all be Cortex M0+). This 32 Bit architecture is superior to Atmega328P (the typical MCU used in Arduinos) in every respect (be it power efficiency, pure performance, sleep current with wakeup timer, price to performance/flash size ratio, peripherals quality and quantity, etc etc.). Just 1 example: the used ADC is 12 Bit with hardware oversampling support (vs 10 Bit without oversampling on Atmega328)

@monte I'll sum it up:
Android App - might be open source in the future
Gateway - not open source, but open
Server Code (cloud) - no
Sensor Node - no
Heat Control - no

In the future the Android App might become open source. Anybody can build a UI, because the data needed for that is available from the gateway.

I wish I'd use my own design for the gateway but to finance that, I'd have to sell thousands of these devices because it's a very time intensive task requiring specialists. Currently the gateway is running on an Orange Pi Zero board with a custom hat. This is why it's the most expensive part. The communication Orange Pi <-> Hat is via USART.

@evb I'm doing RFM69W based tests rights now. It would be good to compare figures about packet loss in a more scientific way.
Right now I am sending from 5 custom nodes (max 10 meters from custom gateway) every 30 seconds. That's 600 messages per hour.
I have a second gateway only listening on that frequency and counting messages. This 2nd gateway has missed 11 messages in 1 hour.
That's a packet miss rate of 1.8% (while RSSI is always stronger than -80 dBm).
A quick research in the internet shows ~1% should be more or less normal.

One thing that caught my eye was data whitening. If a message contains multiple zeros in succession, this can lead to the receiver not waiting till the end of the message.
Solutions: Using dating whitening or encryption.

The temperature node has its own web page now: Canique Climat

@Puneit-Thukral You're mixing up the sensor node and the Vaillant heat control system. The minimum input voltage is 5V for the heat control system (only). This has nothing to do with the used MCU, but the 7-8-9 Vaillant interface usually works with 24V. So usually the input voltage is 24V anyway.
The interface for the Vaillant heat system is usually as follows:
24V input => roughly 11V to 17V output on the CTL pin to regulate the boiler temperature
If you used 5V on the input you'd only be able to regulate up to max. 5V.
The Vaillant heat control system (it's the second picture, the one with the box) does not run from batteries. It gets power directly from the Vaillant (or compatible) heating system.

The single AA battery temperature/humidity node runs from a single 0.8V-1.6V battery. You can see the battery in the picture - in this case it's an Eneloop although I'd recommend Alkaline batteries for devices that run for years. To run from a single battery the node has a boost circuit integrated that boosts the voltage to 1.85V.
On all devices (sensor nodes, heating control, gateway) I'm using a variant of ARM Cortex M0+ or Cortex M0. (Eventually it will all be Cortex M0+). This 32 Bit architecture is superior to Atmega328P (the typical MCU used in Arduinos) in every respect (be it power efficiency, pure performance, sleep current with wakeup timer, price to performance/flash size ratio, peripherals quality and quantity, etc etc.). Just 1 example: the used ADC is 12 Bit with hardware oversampling support (vs 10 Bit without oversampling on Atmega328)

@monte I'll sum it up:
Android App - might be open source in the future
Gateway - not open source, but open
Server Code (cloud) - no
Sensor Node - no
Heat Control - no

In the future the Android App might become open source. Anybody can build a UI, because the data needed for that is available from the gateway.

I wish I'd use my own design for the gateway but to finance that, I'd have to sell thousands of these devices because it's a very time intensive task requiring specialists. Currently the gateway is running on an Orange Pi Zero board with a custom hat. This is why it's the most expensive part. The communication Orange Pi <-> Hat is via USART.

@evb If it's intermittent, chances are high that it is noise. But the noise could also stem from the gateway itself. Just a theoretical example to illustrate what I mean: access to an SD card on the gateway => noise. Then it would appear that you randomly lose messages, although it coincides with an access to the SD card.

It's time intensive to spot stuff like this. You could setup a gateway that just scans the same frequency (in promiscous mode) and samples RSSI. You could log each detection of a transmission (when RSSI values go from say -100dBm to -70 dBm) and then check if something is being transmitted from your nodes at the time in question.

Or you could setup a second gateway right next to your first one and see if that one is receiving the message. If one of them is receiving the message, it's probably a gateway issue. If neither is receiving the message there could be another transmission ongoing or it's a node issue.

@evb For wireless 868 MHz communication the system uses its own protocol, designed for security and short messages. (For example I use every bit of the message, bit shifting etc. is applied to minimize payload length.)
From a programming perspective it isn't based on 8Bit. It's 32Bit, Cortex-M0+. Programmed in C/C++. Typical power consumption of the whole sensor node in sleep @ 1.85V = 1uA (1020 nA to be accurate).

For integration into your home controller system, the Gateway is the right place. You send MQTT messages to / receive MQTT messages from the Gateway. It talks to the nodes, you talk to the Gateway.

So the final picture looks like this (from a developer perspective):
You send a message to the Gateway saying "Set boiler temperature to 54°C" and get back an ACK. The temperature is set.
Or you subscribe to an MQTT channel from the gateway and then are notified about every change on that channel until you unsubscribe. E.g temperature/humidity in refrigerator. You also get the latest value of that channel upon subscription immediately.

To name a few, there are channels for battery voltage, sensor values, firmware revision, sensor label.

The gateway also supports:
Configuring alarms (again via MQTT) and being notified about alarm conditions. You send a JSON message with alarm parameters, like time + trigger (like humidity must be below/above threshold) and then get notified on an MQTT alarm channel.

@evb when doing range tests I also tested range through multiple buildings, so there was no clear line of sight. Distance was approximately 200 meters @ 13 dBm (max transmission power restricted due to regulations in the EU) with an external 5dbi antenna. That was the edge where TX was working.

For door nodes, ACKs and retransmissions are a must. I even use that in my temperature nodes.

@bjornhallberg it's improbable that there's something wrong with the RFM69
you have a frequency marking at the back, and I've never had a module with a wrong marking.

If an RFM69 is being outperformed by an nrf24, than this is kilometers away from normal. 868 MHz will -if used right- always outperform 2.4 GHz in terms of range. Always.
I tested nrf24 years ago and the first thing I did was: dismiss them immediately. It was crap.

Possible causes for low range can be: wrong settings (like coding for a HW but using a W version) or oscillations @ the gateway or @ the node (noise in the supply/gnd voltage, or nearby the device).

@evb I wonder what the lock mechanism looks like. Is it a key? Or some knob that you turn around?

How long did it take you to design the case?

What I forgot to write:
The whole ecosystem consists of:

• Temperature / Humidity Sensor
• Reed Sensor
• Vaillant Heat Control
• Gateway
• Android App
• Web Client

@evb I can't see it clearly on the picture but this seems like a reed sensor to me.
Well, usually the transmitter does not have to be at some specific location. There are reed sensors based on magnets (connected with 2 wires to the transmitter). As soon as the magnets are close to each other, a small current flows (or vice versa). They are just attached to the window/door with some sticky adhesive. The transmitter can well be a meter away.

I can say from experience with Atmega328P, that when drawing ~24uA in sleep and sending every 30 seconds a single battery lasts ~ 1 year.
This can all be calculated (rough estimates).
A basic online calculator for this kind of stuff can be found @ https://oregonembedded.com/batterycalc.htm