MIPC Camera v2

View your MIPC cloud cameras in Home Assistant.

---

This project is a fork

It continues homeassistant-mipc-camera by Alban G. (@0xybo), which is no longer maintained. The reverse engineering of the MIPC protocol that makes any of this possible is entirely their work. This fork is maintained by Busy Child (@BusyChild77) and rewrites the integration around a layered client, a shared update coordinator and a full test suite.

What it does

MIPC is the cloud service behind a family of inexpensive Wi-Fi cameras (Vimtag, and various rebadges). The cameras have no usable local API: they dial home, and the phone app talks to the cloud rather than to the camera.

This integration signs in to that cloud with your account and gives you, for every camera on it:

• a live stream in the Home Assistant camera card, dashboard and media_player casts
• still images, so camera.snapshot and notification attachments work
• an availability state that follows what the cloud reports about the camera

Everything is read-only. The integration does not move, configure or record anything.

Requirements

Home Assistant	2024.12.0 or newer
A MIPC account	the same credentials you use in the MIPC app
Cameras	already added to that account through the app

The integration installs dukpy and pycryptodome; Home Assistant does that for you and both ship prebuilt wheels for every platform it supports.

Installation

HACS

1. HACS → ⋮ (top right) → Custom repositories
2. Repository: https://github.com/BusyChild77/hacs-mipc-camera-v2
3. Category: Integration → Add
4. Open the MIPC Camera v2 card → Download
5. Restart Home Assistant

Manual

1. Copy custom_components/mipc_camera_v2/ into your Home Assistant config/custom_components/ directory, so you end up with config/custom_components/mipc_camera_v2/manifest.json.
2. Restart Home Assistant.

Upgrading from the original integration

This fork uses its own integration domain, mipc_camera_v2, rather than the mipc_camera of the upstream project. That keeps the two from colliding — Home Assistant keys custom integrations by directory name, so sharing a domain means only one of them can ever be installed — and it lets this fork carry its own branding.

The cost is that config entries do not carry over. Home Assistant has no mechanism for moving an entry between domains, so if you are coming from the original integration:

1. Remove the old integration from Settings → Devices & services.
2. Delete config/custom_components/mipc_camera/, or remove it through HACS.
3. Install this one and set it up again with the same account.

Your cameras keep their nicknames, so the entity IDs will usually come back the same. Anything that referenced the old entities by unique ID — automations are fine, they use entity IDs — may need a look.

Configuration

Settings → Devices & services → + Add integration → MIPC, then enter the account username and password. The integration checks them against the cloud before it saves anything, and adds one camera entity per camera it finds.

Each camera becomes a device named after the nickname you gave it in the MIPC app, with its model and firmware filled in. If the cloud stops accepting your password later, Home Assistant raises a normal re-authentication prompt instead of failing quietly.

Adding a camera to your MIPC account after setup? Reload the integration (⋮ → Reload on the entry) to pick it up.

How the stream reaches Home Assistant

The cameras are not reachable on your LAN, so nothing here is a local RTSP pull. Every playback is brokered by the cloud:

 Home Assistant                    MIPC cloud                    Camera
      │                                 │                           │
      │  1. which host serves me?       │                           │
      ├────────── www.mipcm.com:7443 ──▶│                           │
      │◀───────── http://<host>/ccm ────┤                           │
      │                                 │                           │
      │  2. queue + Diffie-Hellman + encrypted login                │
      ├────────────────────────────────▶│                           │
      │◀──────── session id ────────────┤                           │
      │                                 │                           │
      │  3. list the cameras            │                           │
      ├────────────────────────────────▶│                           │
      │◀──────── serial, nickname, online ──┤                       │
      │                                 │                           │
      │  4. give me a stream for <serial>                           │
      ├────────────────────────────────▶│──────── wake up ─────────▶│
      │◀── rtsp://<relay>/live/<serial>_p0_<token> ─┤               │
      │                                 │                           │
      │  5. open that URL ─────────────▶ relay ◀──── video ─────────┤
      │     and repackage it as HLS     │                           │

Two consequences shape the whole design:

• The RTSP URL is single-use and expires with the session (about thirty seconds). It is fetched again every time a stream starts, never cached and never logged.
• Everything after step 1 is plain HTTP. That is the server's choice, not this integration's. See the security recipe for what that means for you.

Limitations

• Cameras added to the account after setup need an integration reload.
• No PTZ, recording, motion events or two-way audio. The endpoints exist and are described in the protocol recipe; none of them are wired up.
• The account is polled every 30 seconds for online/offline state. There is no push.
• One Home Assistant instance per account works best; the cloud is not fond of many concurrent sessions for the same user.

Documentation

Recipe	For
Development	architecture, the vendored client, adding a platform
Protocol	the MIPC protocol reference and adding an endpoint (lives with the client)
Testing	running the suite, the fakes, writing tests for each layer
Troubleshooting	debug logging, symptom-to-cause table, capturing raw traffic
Security	what is sent where, credential handling, reporting a vulnerability
CLAUDE.md	conventions and guardrails, for humans and coding agents alike

Development

python -m venv .venv && source .venv/bin/activate
pip install -r requirements_test.txt
pytest                       # whole suite, with coverage
ruff check custom_components tests brands && ruff format --check custom_components tests brands
python scripts/check_vendor.py   # the vendored client has not been hand-edited

The suite never touches the network, and never touches MIPC: the client is mocked whole. What it covers is the Home Assistant layer — entities, the coordinator, the config flow.

The MIPC client is a separate project

Everything that speaks to MIPC — the wire format, the handshake, the cryptography, the retry policy — lives in mipc-client, and a generated copy of it ships inside custom_components/mipc_camera_v2/_vendor/. That is a copy rather than a dependency because HACS installs an integration by copying one directory and only pip-installs what manifest.json names, which has to be published to PyPI.

Change the client there, then refresh the copy:

./scripts/sync_client.sh            # from the sibling checkout
./scripts/sync_client.sh --check    # or just report drift

The same client is what mipc-restream uses to publish these cameras as plain RTSP for an NVR such as Shinobi. If you already run that, point a Generic Camera at it and keep this integration for snapshots and online state.

Credits

• Alban G. (@0xybo) — the original integration and the analysis of the MIPC protocol this fork is built on. Without that work there would be nothing to fork.
• Busy Child (@BusyChild77) — this fork.

custom_components/mipc_camera_v2/_vendor/mipc_client/crypto/js/ contains scripts served by mipcm.com, included verbatim so that the key exchange and request signing stay byte-for-byte compatible with the service.

License

MIT — © 2023 Alban G. (@0xybo), © 2026 Busy Child (@BusyChild77).

This project is not affiliated with, endorsed by, or connected to MIPC or its operators.