Choose Home Assistant Core imou when you want the built-in, Home Assistant-reviewed path with automatic updates and its documented camera, button, switch, and sensor entities. Evaluate the separately installed Imou Life component from Imou-OpenPlatform/Imou-Home-Assistant when you specifically need features it currently adds. They are distinct integrations; verify repository ownership, names, releases, and migration guidance again on publication day.
Current landscape
Home Assistant introduced the imou hub in Core 2026.7. Its integration page identifies it as Cloud Polling and lists @Imou-OpenPlatform as an integration owner. Separately, the GitHub organization Imou-OpenPlatform publishes the HACS-oriented repository Imou-Home-Assistant, whose installed integration is named Imou Life. Those facts support attribution, but product naming should still follow the pages visible on publication day.
What Core documents
The Core page says devices attached to the Open Platform account are discovered automatically. Device channels expose SD and HD live-view camera entities. Supported actions, toggles, and measurements become buttons, switches, and sensors only when reported for that device. It documents App ID, App secret, and server-region setup, and states that the integration polls cloud APIs every two minutes for device list and online status.
What the separate component documents
The maintained repository describes an independently installed component integrated with Imou Open Platform. Its README and releases may expose options or event-push features beyond the Core page. For example, repository release notes should be checked for current configuration and event-push behavior. Treat repository documentation as authoritative for that component only, not as proof that Core has the same feature.
Decision criteria
Prefer Core if built-in lifecycle, Home Assistant release testing, and the documented Core entity set meet the need. Consider the separate component only after listing a concrete missing requirement and confirming it in the current repository documentation. Also compare minimum Home Assistant version, issue activity, release cadence, backup procedure, and whether both integrations would compete for the same devices or quota.
A safe comparison procedure
- Back up Home Assistant. 2. Record entity IDs and automations. 3. Read the current Core integration page and current repository README. 4. Test one path with one device. 5. Compare only capabilities actually exposed for that device. 6. Measure API use in the Open Platform console. 7. If changing paths, disable the old config entry before enabling the new one and repair entity references deliberately.
Do not run both casually
Architecture recommendation: avoid polling the same fleet through both integrations merely to compare dashboards. Duplicate cloud activity can consume more App ID quota and create duplicate entities or competing commands. If a short overlap is necessary, isolate the test, monitor usage, and keep a rollback plan. Neither Home Assistant nor Imou documentation cited here promises conflict-free dual operation.
Naming and attribution check
Publication-day gate: confirm that the Core URL remains /integrations/imou/, that the repository remains under Imou-OpenPlatform, that the custom integration is still named Imou Life, and that maintainers have not published a preferred migration path. This draft deliberately does not use “official” as a blanket adjective because Core governance and vendor-maintained distribution are different facts.
Community answer, not a sales funnel
This is peer help. There is no price comparison, lead form, or claim that one choice fits every household. If Core covers your device and automation, staying built-in is usually simpler. If the separate component documents a feature you require, test it carefully and report reproducible issues with redacted diagnostics.
Pitfalls
Do not paste App secrets into forum posts, infer device support from another model, assume a HACS repository is part of Core, or assume Core contains every repository feature. Avoid migration instructions based only on entity names observed in an old release. Cloud availability and Open Platform quota affect both paths.
Where to ask next
For Core behavior, use the Home Assistant integration documentation and linked Core issue tracker. For the separately maintained component, use its repository issues and release notes. Include Home Assistant version, integration path, server region, device capability information, and redacted diagnostics.
Verification discipline
Treat the linked live documentation as the boundary of the claim. Capture the page and review date in the release ticket, and recheck method names, fields, permissions, regions, and status values before publication. Console behavior and repositories can change after this draft. If the live source disagrees with this article, update the article rather than preserving an outdated assertion.
Secret handling
Keep App Secret values and administrator access tokens on a trusted backend. Do not place them in Home Assistant YAML shared publicly, browser bundles, mobile logs, screenshots, sample repositories, or support tickets. Redact device identifiers and live addresses in diagnostics. A live URL is operational data and should be distributed only through the authorization boundary designed by the application owner.
Capability and service boundaries
A documented platform method does not prove that every device, channel, account, or subscribed service supports the same outcome. Test with the actual account region and target device family. Present missing controls as a capability or service question first, then gather diagnostics, instead of promising universal behavior or inventing a model matrix.
Observability
Record the request ID, method, region, result code, and a redacted resource identifier for backend calls. Add timestamps around each stage so operators can distinguish local validation, platform rejection, device availability, and downstream delivery. Logs must never contain App Secret values, full administrator tokens, reusable live URLs, or unredacted callback payloads.
Rollout practice
Start with one test application, one account region, one device, and one channel. Validate the happy path and an intentional failure before expanding. A staged rollout makes region mistakes, quota pressure, unsupported capabilities, and stale credentials visible while the affected inventory is still small.
Architecture status
Unless a sentence is explicitly attributed to Imou or Home Assistant documentation, workflow choices in this article are recommendations, not platform guarantees. Queue design, caching, reconciliation, alert thresholds, and retry policy belong to the application operator. They should be tuned from measured behavior without being presented as an Imou SLA.
Change control
Put region, callback, credential, schedule, and integration changes through review. Record the old value, intended value, operator, validation request, and rollback condition. This is especially important where a seemingly small configuration edit can change cloud traffic or make an entire device group unavailable. Review current documentation again when applying a saved runbook.
Test evidence
A useful community or production report states what was tested without exposing private material: Home Assistant or application version, integration path, account region, method, device capability category, UTC time, and redacted result. Separate observed evidence from interpretation. That makes later maintenance possible even when repository releases or platform documentation have moved.
Exit criteria
Define success before rollout: the intended resource appears, one controlled action or event completes, resource use remains visible, and rollback has been rehearsed. Also test a wrong-region or unavailable-device case so support staff recognize the difference. Document only what the test proves, and leave unsupported device families or account configurations explicitly unresolved.
When asking the community for help, identify which of the two integrations produced the evidence and link the exact documentation or release used. Avoid combining observations from Core and the separate component into one capability claim; similar entity names do not establish identical implementation or support.
Official sources
Live-source review date: 2026-08-31. Recheck before publication.
Top comments (0)