pyibaby

An open-source client library for iBaby monitor cameras (M6S / M7 / M7T and relatives), reverse-engineered for interoperability so the cameras can be used without the vendor's Windows/Android app and with reduced dependence on the iBaby cloud.

The cameras are built on ThroughTek's PPCS/PPPP P2P stack. This project reimplements every layer needed to reach a camera in pure Python:

• the iBaby cloud API (get-secret-key -> login -> device list);
• decryption of each camera's per-device P2P password;
• the generateP2Ppass login token (standard AES, recovered from the native library, no proprietary code required);
• the PPPP transport (LAN discovery, handshake, reliable DRW channels);
• the control channel (BABYCARE: login, media start/stop, PTZ, two-way audio) and the H.264 / G.711 media framing.

See docs/protocol.md for the full protocol write-up.

Status

Working end to end on the LAN. The cloud client, credential decryption, login-token generation, and protocol/codec parsing are validated against live traffic and two physical cameras. The LAN transport (pyibaby/pppp.py) performs discovery, handshake, login, and reliable video reception: tools/grab_frame.py connects to a camera with no vendor software involved and decodes live 1080p H.264. The intended end state is a small producer that exposes a camera as RTSP/WebRTC (via go2rtc) and ONVIF for NVRs, plus a V4L2 source and a Home Assistant integration.

This targets the p2p_provider != 0 (PPCS/PPPP) cameras. ThroughTek's other generation (provider == 0, TUTK IOTC) is handled directly by go2rtc's pkg/tutk and is out of scope here.

Layout

pyibaby/
  crypto.py     RNCryptor, account-password hashing, generate_p2p_token
  cloud.py      IBabyCloud: get-secret-key / login / camera_list
  protocol.py   PPPP framing, DID encoding, BABYCARE commands, AV frame header
  pppp.py       LAN transport: discovery, handshake, reliable DRW channels
  client.py     LANCamera: connect, control, pull video
  servers.py    init_string -> PPCS supernode list (WAN path)
  relay.py      ThroughTek relay fallback for symmetric-NAT pairs
docs/protocol.md        protocol reference
docs/nat-cloud-mode.md  remote access: hole-punching, NAT types, relay status
tests/            unit tests (crypto vectors, framing)

Remote access

The LAN path is the supported one. For reaching a camera from another network, use a WireGuard or Tailscale tunnel into the camera's LAN - everything here then works unchanged, nothing depends on ThroughTek staying online, and video never leaves infrastructure you control.

LANCamera.connect_wan() also implements the app's own mechanism: decode the cloud-provided init_string to ThroughTek's PPCS supernodes and UDP hole-punch to the camera. Direct punching works only when neither side is behind symmetric NAT, and raises SymmetricNatError (naming which side) otherwise - which is common on carrier NAT. For that case, connect_wan(allow_relay=True) falls back to a ThroughTek relay, which is validated end to end for control, sensors, and video. It is opt-in because the relay carries your camera's video through ThroughTek's servers.

See docs/nat-cloud-mode.md for the protocol detail, the live measurements, and what would be needed to finish the relay.

Usage (sketch)

from pyibaby import IBabyCloud, LANCamera

cloud = IBabyCloud()
cameras = cloud.login("you@example.com", "password")   # reads camera_list
cam = next(c for c in cameras if c.is_pppp)

lan = LANCamera(cam).connect()        # LAN discovery + handshake + login
lan.start_video()
lan.pump(2.0)                          # service the link for 2s
open("out.h264", "wb").write(lan.video_bitstream())
lan.close()

Credentials and camera UIDs are not stored in this repository; supply them at runtime (environment, a local untracked config, or a secret manager).

RTSP / WebRTC via go2rtc

pyibaby.bridge is a live producer that connects to a camera and writes raw Annex-B H.264 to stdout, which go2rtc ingests directly as an exec: source - no ffmpeg needed for video. go2rtc then re-serves the camera as RTSP / WebRTC / HLS / MJPEG and fans one camera session out to many consumers (NVRs, Frigate, VLC, Home Assistant, ...).

See examples/go2rtc.yaml. In short:

IBABY_EMAIL=you@example.com IBABY_PASSWORD=... go2rtc -config examples/go2rtc.yaml
# -> rtsp://127.0.0.1:8554/nursery

Validated end to end: camera -> pyibaby.bridge (PPPP) -> raw H.264 -> go2rtc -> RTSP, decoded back as 1080p with no vendor software in the loop.

RTSP server (pyibaby.rtspd)

pyibaby.bridge is an exec: producer (go2rtc spawns it). Some consumers can't spawn a process - notably Home Assistant's bundled go2rtc, which is locked to exec: allow_paths: [ffmpeg] and will not run Python. For those, pyibaby.rtspd runs as its own RTSP server: it holds one camera session and serves H.264 + G.711 u-law over RTSP (RTP interleaved on TCP), fanning the one session out to multiple local clients. It doubles as a plain RTSP source for any NVR.

IBABY_EMAIL=you@example.com IBABY_PASSWORD=... python -m pyibaby.rtspd --port 8554 --path /cam
# -> rtsp://127.0.0.1:8554/cam  (point go2rtc / an NVR / ffmpeg at this URL)

Validated end to end against go2rtc 1.9.14: it ingests the stream over rtsp+tcp and detects H264 High@4.0 video + PCMU/8000 audio. Two concurrent camera sessions are supported by the hardware, so the control/sensor path and the RTSP video path can run side by side.

Branching

master is the primary branch.

Licence

MPL-2.0.