C'est un "vieux" thermostat wifi (Heatmiser) ... Il n'y a jamais eu de MAJ je pense .. mais il fonctionne
Je suis passé en IP fixe V4 full-stack

Quand je vois que j'ai actuellement 1400 adresses IP bloquées par fail2ban pour des tentatives de connexions sur mon serveur SSH, perso je ne me risquerais pas à mettre un truc pas mis à jour depuis 8 ans accessible depuis l'extérieur, sans aucun chiffrement (même le mot de passe, ou son hash circule en clair, et il n'y a probablement aucun mécanisme anti rejeu), d'autant plus sur le port HTTP par défaut, sans doute l'un des plus scannés...

Dans quelques jours, ton port 80 ouvert sera probablement indexé par shodan.io et visible par tous les attaquants potentiels.

je pense qu'UDP n'est pas le seul protocole requis pour que l'accès fonctionne. Je dirais de rajouter une ligne similaire avec tcp (voire d'autres protocoles si ça bug toujours), pour que cela marche. C'est en tout cas une solution pour protéger le port 80 qui va dans tous les cas être scanné activement.

edit : en effet ça a l'air dangereux de le mettre en public sur Internet

La règle c'est ce qui est connecté directement à Internet doit recevoir des mises à jour de sécurité régulièrement.

Les équipements pour une raison ou une autre ne reçoivent pas de mise à jour de sécurité devraient être accessible uniquement via un équipement tiers.

Par exemple si tu as un Raspberry Pi, il est possible d'exposer SSH de ce Raspberry Pi sur Internet et d'utiliser la commande SSH (elle est même dispo sous Windows 10 maintenant) pour te connecter à ton thermostat à distance.

Exemple :
ssh -p 522 -L 80:192.168.0.10:80 login@mon_ip_publique

522 : le port où Raspberry Pi écoute avec SSH (éviter le port 22 par défaut)
login : le login sur ton Raspberry Pi
192.168.0.10 : IPv4 de ton thermostat
mon_ip_publique : IPv4 publique de ta box internet

il faudra te rendre sur http://127.0.0.1/ pour accéder à ton thermostat hors de chez toi (après avoir passé la commande SSH)

pour du vieux matos avec l'https troué et pas de mise à jour possible, j'ai tout remis en http port 80 et j'ai mis un reverse proxy https nginx en frontal avec certificats lessencrypt.

non la redirection est en http. le reverse proxy fait aussi de la redirection ipv6 vers ipv4 pour vieux truc pas v6.
server {

        server_name dibule.example.info;
#       access_log  /var/log/nginx/dibule.example.info.log main;

        location ~* / {
                proxy_pass http://192.168.1.99;
#                proxy_redirect     http://192.168.1.99 https://dibule.example.info;
                proxy_redirect     off;
                proxy_set_header   Host             $host;
                proxy_set_header   X-Real-IP        $remote_addr;
                proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
                proxy_set_header   X-Forwarded-Host $host:$server_port;
                proxy_set_header   X-Forwarded-Proto $scheme;
                proxy_hide_header   Referer;
                proxy_hide_header   Origin;
                proxy_set_header    Referer           '';
                proxy_set_header    Origin            '';

                }

   
    listen [::]:443 ssl ; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/dibule.example.info/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/dibule.example.info/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}
server {
    if ($host = dibule.example.info) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


        listen 80 ;
        listen [::]:80 ;
    server_name dibule.example.info;
    return 404; # managed by Certbot

}
L'authentification sur dibule est un simple username/password.
Le serveur nginx tourne sur une carte arm64 Orange Pi PC2.
La famille des dibules est référencée au niveau dns par des CNAME qui pointe vers le serveur nginx qui lui a seulement un AAAA.