Whether the device is a server or client doesn't actually matter that much. What does matter is how large the IP address range able to connect to the device is. Limiting it to a small number of addresses means connection attempts from everywhere else can be ignored, as if a firewall dropped those packets without any further processing. If you make the device a client, you can ignore all connection attempts, except those related to connections initiated by the device itself (assuming ftp and passive transfers, and similarly bass-ackward protocols where the server connects to the client, are not used).
Since the physical network these devices are used in are rarely secure, you still need to encrypt and secure the communications, and both ends need to authenticate each other. I'm very interested in the
Microchip ATECC608B for both the encryption and certificate-based authentication, because Mouser sells these in singles for under 1€ apiece. Even with a dedicated crypto IC, connection attempts must be limited to a small set, as otherwise simply making lots of connection attempts works as a denial-of-service attack.
I would implement the physical user interface, the IoT interface, and the actual device as separate units, communicating using a plain serial connection. I'd even allow disconnecting either interface while having the main device running normally. This significantly reduces the complexity in each of these components, and thus makes bugs easier to detect and solve: fewer complex interactions with patterns and consequences that are difficult for humans to encompass, and therefore overall fewer difficult bugs.
Furthermore, instead of an IoT interface, you could actually use a small ARM/RISC-V SoC, and run a proper Linux server and firewall on that. Many of the various
FooPi Zero SBCs suffice for this, although I would avoid Raspberry Pi ones because of their fundamentally problematic hardware USB implementation (which can drop packets in a way that is supposed to not happen per the USB specs), and look for one with eMMC, M.2, or SATA storage (as opposed to microSD cards). In most cases, a single such IoT server should suffice for a household, though, so this would need additional thinking on before deciding.
Just use LoRa instead.
No, it definitely needs an AI that can learn your configuration preferences and heating and energy use patterns, so you don't even need to adjust the settings after a while because the AI does those aitomagically for you. Besides, that requires we gather detailed data on each user, for quality assurance purposes; which of course means we also can "obfuscate" and then sell that data to house insurers for the Actual Big Bucks. Might even consider negotiating package deals, insurance + heating controller, benefiting everyone.
I'm sorry, I just threw up a bit in my mouth.
Anyway, my friends B. Urglar and B. N. Enter would be happy to pay for such data, too, for specific named clients off the books, of course.