Netatmo — Intégration des caméras (Home + Security)

Développement
1

Hello à tous ! :waving_hand:

Comme annoncé sur le sujet du service Netatmo, le développement de l’intégration des caméras Netatmo (gamme Home + Security) reprend officiellement. Ce sujet servira à suivre l’avancement, discuter des choix et organiser les tests.

Un peu d’histoire

Une première PR (#2032) avait été ouverte en mars 2024 pour la caméra intérieure (NACamera), puis fermée automatiquement pour inactivité. Bonne nouvelle : le travail n’a pas été perdu — la branche a continué d’évoluer bien après la PR (découverte des caméras, conversion des appareils Security, récupération de snapshot via ffmpeg, tests complets…). Cette base va être reprise sur un master à jour, nettoyée, et redécoupée en PR de taille raisonnable — leçon retenue des grosses PR du passé :wink:. De mon côté, j’ai du matériel de test !

  • caméras intérieure
  • caméra extérieure,
  • sirène,
  • DoorTag

Le plan, en 3 étapes

Étape 1 — Socle API Security :brick:
Activation de l’API Security dans la configuration du service, découverte des caméras, premières fonctionnalités (statut, WiFi). Les commandes liées à la caméra seront visibles mais désactivées, avec un message d’explication — elles seront débloquées à l’étape 2. L’objectif : une PR compacte et facile à reviewer qui pose les fondations.

Étape 2 — L’image :camera:
La fonctionnalité caméra à proprement parler : récupération du flux (URL VPN Netatmo avec bascule automatique sur l’URL locale quand c’est possible), rafraîchissement périodique de l’image, affichage dans le dashboard caméra de Gladys — comme les caméras RTSP.

Étape 3 — Les événements et modules associés :bell:
Détection de mouvement, détection de personnes, et les modules rattachés aux caméras (sirène intérieure, capteurs d’ouverture DoorTag) selon le matériel disponible.

Et ensuite : la réception des événements en temps réel par webhook (via Gladys Plus), qui bénéficiera à terme à tous les appareils Netatmo, pas seulement aux caméras.

Pourquoi maintenant ?

Le service vient de recevoir 4 PR de correctifs et de refactoring qui assainissent la gestion de la connexion, des valeurs et de la découverte : la base est saine pour construire dessus.

Si vous avez des caméras Netatmo (intérieures, extérieures, sonnette), manifestez-vous ici — des testeurs seront les bienvenus dès les premières PR ! :raising_hands:

2

Bonne nouvelle : les étapes 1 et 2 du plan sont codées, en PR et testées en réel chez moi (NACamera intérieure + NOC extérieure), et le live du dashboard fonctionne aussi ! :tada:

Ce qui marche aujourd’hui sur ma pile de branches :

  • Découverte des caméras (NACamera + NOC) via l’API Security, avec statut de surveillance et qualité WiFi
  • Image de la caméra dans la box Caméra du dashboard, rafraîchie à chaque cycle (résolution automatique de l’URL locale avec repli VPN)
  • Commande de surveillance ON/OFF depuis le dashboard
  • Bouton « live » de la box Caméra fonctionnel (flux HLS via le service rtsp-camera), avec un sélecteur de qualité du flux sur la page de l’appareil
  • Bonus : la découverte permet maintenant de mettre à jour un appareil déjà créé quand de nouvelles fonctionnalités apparaissent (fini la migration DB à chaque ajout)

Les PR, dans l’ordre de review/merge (chaque PR stackée se réduit automatiquement au merge de sa parente) — @pierre-gilles quand tu as un moment :folded_hands: :

  1. #2620 — fix découverte : modules hors tension reconstruits proprement (à merger en premier, nécessaire pour tester le reste)
  2. #2617 — fix valeurs falsy (pluie 0 mm, 0 °C, angle 0°… n’étaient pas remontés)
  3. #2619 — refactor déclaratif des updates (stackée sur #2617, -364 lignes net)
  4. #2618 — durcissement connexion/tokens (indépendante)
  5. #2621 — CAM-1 : socle API Security + découverte caméras
  6. #2624 — flux « Mettre à jour » en découverte
  7. #2623 — CAM-2 : image + commande surveillance
  8. #2625 — CAM-3 : live streaming + sélecteur de qualité
  9. #2622 — fix SVG en dev (indépendante, mergeable à tout moment)

Les 4 premières sont des PR d’assainissement du service actuel, volontairement petites et sans changement de comportement (sauf les fixes), qui préparent le terrain caméra.

La suite : les événements (mouvement, personnes) probablement via webhooks, puis les modules pontés (sirène NIS, capteurs d’ouverture NACamDoorTag — ils apparaissent déjà en « non supporté » dans la découverte).

L’appel aux testeurs tient toujours, surtout si vous avez une config différente de la mienne (caméra accessible uniquement via le VPN Netatmo notamment) ! Une image de test sera disponible dans 30 minutes : docker pull terdious/gladys:netatmo-camera

3

Un point technique pour la transparence sur le live : il fonctionne, mais il est lent à démarrer et peu fluide, et ce n’est pas entierement lié à Netatmo ni à la PR #2625 — c’est le pipeline du service rtsp-camera qui ré-encode tout flux entrant en h264 1920px @ 25 fps.

Mesures faites chez moi sur le flux Netatmo (déjà en h264) :

  • le ré-encodage upscale la source (720p → 1080p, et même une source 384x216 repart en 1080p :sweat_smile:), à ~0.3x du temps réel sur ma machine → le transcodeur prend du retard sur la playlist live, segments sautés, ~19 s avant le premier segment
  • le -r 25 forcé duplique une frame sur deux (la caméra produit ~12-24 fps)
  • en remplaçant l’encodage par un simple -c:v copy (remux HLS chiffré sans ré-encodage, testé localement) : premier segment en ~3 s, vitesse stable 1x, quasi plus de coupures — CPU proche de zéro

Je proposerai donc une PR core rtsp-camera séparée dans ce sens : stream-copy quand la source est déjà h264 et sans rotation, sinon ré-encodage sans upscale et au fps de la source. Ça profiterait aussi aux caméras RTSP classiques (et aux petits CPU type Raspberry Pi). @pierre-gilles je te ferai un post dédié avec le détail avant d’ouvrir quoi que ce soit, dis-moi si tu as déjà un avis :slightly_smiling_face: