Netatmo — Camera Integration (Home + Security)

Development
1

Hello everyone! :waving_hand:

As announced in the Netatmo service topic, the development of the integration of Netatmo cameras (Home + Security range) is officially back on track. This topic will be used to follow progress, discuss choices, and organize testing.

A bit of history

A first PR (#2032) was opened in March 2024 for the indoor camera (NACamera), then closed automatically for inactivity. Good news: the work has not been lost — the branch continued to evolve long after the PR (discovery of cameras, conversion of Security devices, retrieval of snapshots via ffmpeg, full tests…). This base will be taken up on an up-to-date master, cleaned up, and split into reasonably sized PRs — lesson learned from the big PRs of the past :wink:. On my side, I have test equipment!

  • indoor cameras
  • outdoor camera,
  • siren,
  • DoorTag

The plan, in 3 steps

Step 1 — Security API Foundation :brick:
Activation of the Security API in the service configuration, discovery of cameras, first features (status, WiFi). The commands related to the camera will be visible but disabled, with an explanatory message — they will be unlocked in step 2. The goal: a compact and easy-to-review PR that lays the foundations.

Step 2 — The image :camera:
The camera functionality itself: retrieval of the stream (Netatmo VPN URL with automatic switch to the local URL when possible), periodic refresh of the image, display in the Gladys camera dashboard — like RTSP cameras.

Step 3 — Events and associated modules :bell:
Motion detection, person detection, and the modules attached to the cameras (indoor siren, DoorTag opening sensors) depending on the available equipment.

And then: the reception of real-time events via webhook (via Gladys Plus), which will eventually benefit all Netatmo devices, not just the cameras.

Why now?

The service has just received 4 PRs of fixes and refactoring that clean up the management of the connection, values, and discovery: the base is healthy to build on.

If you have Netatmo cameras (indoor, outdoor, doorbell), speak up here — testers will be welcome as soon as the first PRs are ready! :raising_hands:

2

Good news: steps 1 and 2 of the plan are coded, in PR and tested in real life at my place (NACamera indoor + NOC outdoor), and the dashboard live stream also works! :tada:

What works today on my branch stack:

  • Camera discovery (NACamera + NOC) via the Security API, with monitoring status and WiFi quality
  • Camera image in the Camera box of the dashboard, refreshed with each cycle (automatic resolution of the local URL with VPN fallback)
  • ON/OFF monitoring command from the dashboard
  • « Live » button of the Camera box functional (HLS stream via the rtsp-camera service), with a stream quality selector on the device page
  • Bonus: discovery now allows updating an already created device when new features appear (no more DB migration with each addition)

The PRs, in review/merge order (each stacked PR automatically reduces when its parent is merged) — @pierre-gilles when you have a moment :folded_hands: :

  1. #2620 — fix discovery: off-power modules properly rebuilt (to merge first, necessary to test the rest)
  2. #2617 — fix falsy values (0 mm rain, 0 °C, 0° angle… were not reported)
  3. #2619 — declarative refactoring of updates (stacked on #2617, -364 net lines)
  4. #2618 — hardening connection/tokens (independent)
  5. #2621 — CAM-1: Security API foundation + camera discovery
  6. #2624 — « Update » flow in discovery
  7. #2623 — CAM-2: image + monitoring command
  8. #2625 — CAM-3: live streaming + quality selector
  9. #2622 — fix SVG in dev (independent, mergeable at any time)

The first four are PRs for cleaning up the current service, intentionally small and without behavioral changes (except for the fixes), which pave the way for the camera.

Next up: events (motion, people) probably via webhooks, then bridged modules (NIS siren, NACamDoorTag opening sensors — they already appear as « unsupported » in discovery).

The call for testers still stands, especially if you have a different setup than mine (camera accessible only via the Netatmo VPN in particular)! A test image will be available in 30 minutes: docker pull terdious/gladys:netatmo-camera

3

A technical point for transparency on the live feature: it works, but it’s slow to start and not very smooth, and this isn’t entirely related to Netatmo or PR #2625 — it’s the rtsp-camera service pipeline that re-encodes all incoming streams to h264 1920px @ 25 fps.

Measurements I took at home on the Netatmo stream (already in h264):

  • the re-encoding upscales the source (720p → 1080p, and even a 384x216 source goes to 1080p :sweat_smile:), at ~0.3x real-time on my machine → the transcoder falls behind the live playlist, skipped segments, ~19 s before the first segment
  • the forced -r 25 duplicates every other frame (the camera produces ~12-24 fps)
  • by replacing the encoding with a simple -c:v copy (encrypted HLS remux without re-encoding, tested locally): first segment in ~3 s, stable 1x speed, almost no cuts — CPU near zero

I will therefore propose a separate core rtsp-camera PR in this direction: stream-copy when the source is already h264 and not rotated, otherwise re-encoding without upscaling and at the source fps. This would also benefit classic RTSP cameras (and small CPUs like Raspberry Pi). @pierre-gilles I’ll make a dedicated post with the details before opening anything, let me know if you already have an opinion :slightly_smiling_face: