EasyAIoT: one stack for camera access, edge inference and alert rules

The silo problem stated in the project's own words

EasyAIoT is described in the README as a cloud-edge-device integrated intelligent algorithm application platform, dedicated to deeply fusing artificial intelligence with the Internet of Things, enabling cameras, sensors and edge compute to work together on site. The chain it covers runs from device onboarding and data collection through to real-time visual analysis, intelligent assessment and alert orchestration, and the README says the entire chain runs on a single software stack.

The problem it names is the one that decides whether such a project is useful. Many smart IoT projects hit the same wall at deployment: video systems, device platforms and algorithm services live in silos, integration is costly, operations are fragmented, and scaling is painful. The claim is that one platform resolves this, because the same software runs in several shapes without multiple versions to maintain and without repeated integration across heterogeneous systems.

That claim is the interesting part, and the evidence for it is in the repository layout rather than in the prose. The top level is a list of the modules themselves, and they are named in upper case the way a monorepo names its packages: WEB, APP, DEVICE, EDGE, SENTINEL, VIDEO, RTC, AI, RUNTIME, POST, VISUALIZE, TWIN, TRANSFORM, PANEL, IDEA, HARNESS, SITE and TERMINAL, plus AI/ and a COMPILE directory that handles multi-platform packaging and delivery.

Each of those names corresponds to a piece of the pipeline, and each is a real directory with code in it. That is a different shape from a single service with a plugin interface, and it is a heavier one to adopt, because a platform with eighteen modules is eighteen things to configure rather than one thing to point at a camera.

The primary language is Python, the licence is MIT, the last push was on 2026-10-16, and the releases are numbered unusually, V201.2.0 on 2026-10-10, V201.1.0 on 2026-09-24 and V201.0.0 on 2026-09-23.

Four deployment shapes, from a 2GB edge box to an appliance

The most concrete operational detail in the README is the hardware tiering, because it tells you how the platform scales down as well as up.

The same software can run a closed smart loop on a 2 GB edge standalone, described as the edge tier. It can land on a 4 to 8 GB edge box, the mini tier, for single-point intelligence. It can ride AI all-in-one cameras for floor-level coverage. And it can pack into an enterprise full-stack appliance with IoT management, massive video access and AI analysis.

The claim attached to this is that there are no multiple versions to maintain and no repeated integration across heterogeneous systems, which is the direct answer to the silo problem named earlier. Whether a single codebase really does span a 2 GB edge box and an enterprise appliance is the kind of claim that only holds up in deployment, but the tiering is at least stated with specifics rather than adjectives.

The packaging is handled by COMPILE, and the platforms it targets are listed in detail: Ubuntu, CentOS and RHEL 7 to 9 on x86 plus CentOS ARM with packages per el7, el8 and el9, Kylin, openEuler, Windows, macOS and ARM. The presence of CentOS ARM alongside x86 and the two Chinese distributions, Kylin and openEuler, says something about where this is built to run, and it is a stronger compatibility statement than most projects make.

The `COMPILE` directory at the repository root, alongside the per-module directories, is the mechanism for all of that. The `docs/` directory, the `.scripts/` directory and the `.pnpm-store/` directory at the root also tell you the tooling: a pnpm store implies a Node-based build for the WEB and APP front ends alongside the Python services, and the `.doc/` directory holds documentation that is not the README.

How cameras get in: GB28181, ONVIF and bridged consumer cameras

Camera access is the part of the platform that has to interoperate with what people already have installed, and the README describes three routes.

The first two are the standard protocols for professional and semi-professional video: GB28181 and ONVIF multi-protocol camera access.

The third is the one that is unusual, and it is called RTC consumer-camera P2P bridging, based on go2rtc. The listed camera brands are Tapo, Tuya, Ring, Nest, Xiaomi, Wyze, DoorBird, GoPro and Roborock, and the README explains the reason for each: store Tapo fill-in, Tuya white-label onboarding, overseas Ring and Nest doorbells, Xiaomi reuse, Wyze low-cost scale-out, DoorBird intercom, GoPro mobile views and Roborock vacuum cameras. The pitch is one-click Web onboarding into unified video and AI judgment.

That list is worth reading carefully, because consumer cameras are the ones that typically have no ONVIF and no RTSP. A doorbell camera and a robot vacuum camera are not part of any video management system, and the usual answer is that you cannot get them into one. Bridging their peer to peer streams into a unified video layer, and then pointing the inference engine at that layer, is the part of this platform that is genuinely different from an ONVIF-capable VMS.

The bridge is based on go2rtc rather than being written from scratch, which means the hard part of talking to a dozen vendor P2P protocols is delegated to an existing project, and the platform's own work is the onboarding and the unification.

There is also DJI dock and drone aerial view access in the list, which covers the professional drone and docking-station category where the video source is a moving airframe rather than a fixed camera.

Inference on a compiled runtime, and SAM doing the labelling

The AI capability list is where the engineering claims are most specific, and the RUNTIME module is the interesting one.

It is described as a native high-speed execution layer, a compiled binary that owns pull and decode, YOLO inference, boxed push and multi-channel raw forward. The stated benefit is lower CPU and memory use and steadier latency than interpreted paths, and the claim is that one binary covers realtime, snap, patrol and forward. Those four names map onto the task types also listed separately as real-time, snapshot and patrol algorithm tasks, so the pipeline has a fixed set of shapes rather than an open-ended plugin surface.

The algorithms themselves include YOLO object detection and SAM zero-shot auto-annotation, plus face and plate recognition. The SAM part is the one with a practical payoff. Labelling training data is the expensive part of deploying a detector, and zero-shot auto-annotation lets you bootstrap a dataset from a set of already-running cameras without a labelling team, which is a real reduction in the cost of a first deployment.

The face and plate recognition, and the alert side of the platform, carry the obvious governance dimension, and it is worth stating plainly because the platform is designed to run inference close to the device while the management layer aggregates alerts and evidence above it. That architecture means the videos being analysed may never leave the site, which reduces the exposure, but the aggregation layer still holds the derived results, and the deployments that use face and plate recognition carry legal requirements that vary by jurisdiction. The repository does not discuss data retention, consent or access control for the alert and evidence store, and for a platform that routes identity information into a management surface, that gap is the first thing to ask about.

The TWIN module name suggests a digital twin of the device estate, and TRANSFORM a data transformation layer, and VISUALIZE the presentation tier, though the available text does not describe their behaviour in detail.

POST rules that change behaviour without retraining a model

The POST module is the most transferable idea in the platform, and it is the one a team with existing models would care about most.

POST custom judgment works like this: after detection, filter and composite rules are applied before alerting, and the effect is that you can change rules without retraining models. That is a separation of concerns that is easy to describe and rare to find in packaged form. A detector outputs boxes, and everything a deployment actually wants, a person near a restricted door, a vehicle left in a loading bay, a face on a watchlist, is a predicate over those boxes plus context. Writing that predicate in a rule layer rather than in a model means the deployment changes without touching the training pipeline, and it means the rule set is reviewable by someone who is not a machine learning engineer.

SENTINEL is the companion piece for the cluster side. It is described as a cluster-node sentinel that continuously reveals per-node readiness and schedulable business capacity, requests environment fill-in when gaps appear, and dispatches work by real capability. The phrase by real capability is doing work: capacity-aware scheduling, where a node is picked for the work it can actually take rather than for being free.

There is also federated compute cluster scheduling and an Infinite Federated Edge Cluster mode, described as ordinary development boards working out of the box for on-site intelligence, with local decisions for alerts and evidence that aggregate automatically. The federation model here is the reverse of the usual: rather than a central cluster with thin clients, the edges are the primary compute and the aggregation is secondary.

The remaining named modules complete the picture. TWIN, VISUALIZE, TRANSFORM, IDEA, HARNESS, SITE, TERMINAL, DEVICE, EDGE, VIDEO and the WEB and APP front ends. The repository also carries an ANDROID, IOS and HARMONYOS directory, so the APP module has a mobile footprint, and a testdata directory.

What the repository does not tell you

The honest assessment of this project has to be about the documentation, and it is the main thing separating this from the repositories that are easy to evaluate.

There are no install steps in the README. No dependency list, no configuration file reference, no environment variables, no Docker Compose file at the root, and no command to run. The setup guidance that does exist points to an official website, listed as a raw IP address with a port, which hosts a product introduction, a feature overview, the four hardware tiers, installer downloads and a documentation entry. In other words, the operational documentation lives on a site outside the repository, and the repository is the marketing surface and the source tree.

That is a legitimate choice for a commercial product built in the open, and the presence of the MIT licence, a CODE_OF_CONDUCT pattern, a Gitee mirror with badges and a GitHub repository suggests an active open development model. But it means the things you would check in a repository, the shape of the configuration, the size of the dependency tree, whether the thing starts, are all behind that site.

The descriptions are also written in a register that is worth being careful with. Phrases like giving devices intelligent vision, precise face recognition, risk person deployment and perimeter intrusion detection describe capability categories, and the README itself states that it is a product introduction rather than a technical specification. A reader evaluating this project should treat the capability list as a set of directions to verify rather than as a set of features that exist today.

The multi-language READMEs are a further hint about the audience: English, Simplified Chinese, Traditional Chinese, Russian, French and Korean, and a Gitee mirror with a star badge, which is a distribution strategy aimed at a China-based integrator community rather than at an open source contributor audience.

Editorial conclusion

Adopt EasyAIoT if you are an integrator who already has cameras on GB28181 or ONVIF and a set of vision models you want to run against those streams, and you can tolerate a platform whose documentation is thin. Do not adopt it as a black box, because the repository describes capability in product terms and gives no install steps, dependency list or configuration reference, and check first that your deployment has a real answer for where video and biometric data are stored, since the platform is designed to run inference close to the device while the management layer sits above it.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. soaring-xiongkulu/easyaiot on GitHub