things: an open source IoT module for AI agents and device fleets

One module of a platform, not the platform

The repository is named things and described as the open source IoT module of the United Rhino platform, an AIoT and SaaS base built on Golang and go-zero that combines AI agents, RAG knowledge bases, memory and tool calling.

What the readme is careful to say is the scope. The repository provides the open source IoT module, covering mainly product and device management, the thing model, protocols and device gateways, device data, and OTA. It needs Core, Share and the corresponding runtime dependencies to work. The full enterprise edition, the multi-enterprise public capabilities, the AI features, the industry applications and the developer tooling each have their own modules and delivery paths.

The distinction matters because the readme also states that free use of the enterprise edition software does not mean you get the complete enterprise edition source, and it does not change the open source licence of this repository. The same paragraph notes that the enterprise edition is permanently free for private deployment with no limit on users or devices, and clarifies that free means the platform software, not source licensing, server resources, industry application licensing or human services, and that the hosted SaaS plan has its own resource quotas and is not mixed with private deployment.

The upshot is that this is a module with a defined boundary, published under AGPL-3.0, meant to be read and used alongside the rest of the platform rather than mistaken for it.

A go-zero service layout with several binaries

The build system shows the shape of the thing. The Makefile has a build target that fans out into a set of per-service targets, and the service names in it are worth reading.

build:build.clean mod cp.etc build.api build.dg  build.dm  build.ud

runall:   run.dm run.dg run.ud run.api

So there is an API server, a dgsvr, a dmsvr and a ud, each built separately, and a runall target that starts them together. The individual build rules are plain go build invocations with a build tag:

	@go build -ldflags="-s -w"  -tags no_k8s -o ./cmd/things/thingsvr ./service/apisvr

The no_k8s tag is the interesting detail, since it implies the same code has a Kubernetes path and a standalone path. The module also has a clean target that removes the whole cmd directory, a mod target that runs go mod tidy, and a cp.etc target that copies the configuration files from the API service into the output directory alongside creating the etc and dist folders.

The top-level layout is consistent with that. There is a service/ directory holding the services, an sdk/ directory, a share/ directory, a shell/ directory, a tools/ directory, deploy/ and script/ and scripts/ directories, doc/ for the documentation assets, and a tests/ directory. There is also a compiled thingsEEsvr-linux-amd64 binary committed at the root, which tells you that the project expects people to run a prebuilt Linux executable as well as to build from source.

The container build does the same thing in two stages. The builder uses a Go 1.23.4 alpine image and sets the module proxy and the private module scope before downloading dependencies, then builds the API service into a single binary:

RUN go env -w GOPROXY=https://goproxy.cn,direct
ENV GOPRIVATE=*.gitee.com,gitee.com/*
RUN go mod download
RUN cd ./service/apisvr  && go build -tags no_k8s -o thingsvr .

The final stage is a plain alpine image with the binary and the etc directory copied in, and the entrypoint is the server itself.

Module paths on Gitee and two commented replace directives

The go.mod file tells you more about how this project is assembled than any prose would, and it is worth reading closely.

The module path is gitee.com/unitedrhino/things, not a GitHub path, and the two commented lines under it are replace directives pointing at sibling checkouts:

//gitee.com/unitedrhino/core => ../core
//gitee.com/unitedrhino/share => ../share

Those are the two sibling modules the readme names as required. With the directives commented out, the build resolves core and share from the module proxy at the pinned versions, which is the configuration a standalone checkout uses. Uncommenting them and placing the two repositories next to this one is how you work on all three together, which is the standard Go pattern for a multi-repository project.

The direct requirements are the interesting list. There is go-zero at 1.9.4, the framework the whole platform is built on, and a sibling squirrel module at 1.20.7. The messaging and transport dependencies are paho.mqtt.golang for MQTT, nats.go for NATS, asynq for the background job queue, grpc and protobuf for the service-to-service calls, and gorm for the database access.

Three of the entries are less common and tell you something about what the platform does. yaegi is the Go interpreter, which is what lets rule expressions and device logic be evaluated at runtime rather than compiled in. goja is a JavaScript interpreter, which serves the same purpose for JSON shaped rules. ristretto is a cache library, and mapstructure and gjson with sjson handle configuration and JSON manipulation throughout the codebase. golang-jwt for tokens, uuid for identifiers and protobuf for the wire format complete the direct list.

The Go version is pinned to 1.24.4, and the readme states that source development uses Go 1.24.4 to match the go.mod.

A protocol story: MQTT, CoAP, HTTP and TCP with cloud connectors

The project description names the access protocols and the cloud integrations, and the dependency list is consistent with them.

Devices connect over MQTT, CoAP, HTTP and TCP, and the platform connects out to Alibaba Cloud, Tencent Cloud and Tuya Cloud. The indirect dependency list in the go.mod file is where that shows up: a whole family of alibabacloud-go modules, covering the gateway SPI, the debug helper, the endpoint utilities, the OpenAPI utility, the tea library, the SMS service client, the darabonba OpenAPI and the region endpoints, each pinned to a specific version. Those are the Alibaba Cloud connectors, and the fact that the platform uses the official SDKs rather than a hand rolled client is a reasonable choice for a device platform that has to speak to several Chinese cloud providers.

The thing model, in the readme's own terminology the thing model of products and devices, is the layer that sits between a raw protocol and the application. It is what lets a business application ask for a temperature rather than for a payload from a device address, and it is the reason the platform separates the device gateway from the business API in the first place.

On top of that sit the application-level features the description names: multi tenancy, multiple applications, project management, device management, scene linkage, alarms, screen and panel configuration, and a 3D digital twin. The readme is careful to say that the interface screenshots and demos shown are existing delivery recordings rather than live data, and that a one click device access does not mean every protocol and device needs no adaptation.

The AI side is the reason the repository sits where it does in the platform. The Skills and CLI route, where an AI tool such as WorkBuddy is given a manual or a protocol document and then helps configure products, devices and data fields, is the intended entry point for the fast device access path, with a three step flow of providing the documentation, authorising access, and checking the result.

AGPL-3.0, no releases, and a documentation site that does the explaining

The licensing and the release picture are both unusual, and both are stated directly in the readme.

The licence is AGPL-3.0, with the LICENSE file in the repository as the authority. The readme spells out the obligation it creates: when you modify, distribute or provide a modified program over the network, you must comply with the applicable licence obligations, and other product and commercial licensing terms are handled through the vendor's website or by contacting them.

That network clause is the one to think about. AGPL requires source availability when a modified version is offered as a service, which is a different situation from the permissively licensed libraries most teams assemble, and it is worth raising with whoever owns licensing in your organisation before you put a modified version behind a network interface.

There are no GitHub releases at all. The repository is not archived, the default branch is master, and the last push was on 2026-10-01, three weeks before the current date. Development is therefore happening, but there is no tagged version to pin to and no changelog to read, which means a consumer tracks the branch or tracks a version in the sibling modules.

The documentation is split the way the platform is split. The readme explicitly says that dependencies, installation and configuration steps are to be found in the developer documentation rather than maintained as a second deployment manual in the readme, which is a reasonable choice for a component with as many moving parts but does mean the repository alone is not enough to run it.

The related repositories complete the picture, and they are listed in a table: a ur CLI that provides authorised platform operation tools for developers and their AI, a Docling Go document parsing project aimed at structured parsing for knowledge bases and AI, a Sandbox for AI tool execution and workspace services, and a customised go-zero fork. The readme is careful to note that the customised go-zero is a framework source and documentation, and that it is not the default dependency for every service.

Editorial conclusion

things suits a team that wants the device and data half of an IoT platform under a copyleft licence and is prepared to work with the go-zero conventions the rest of the stack uses, including its Gitee hosted module paths. It does not suit a team expecting a self contained product, because the repository is explicitly one module that needs Core and Share alongside it. Before building it, read the developer documentation rather than the readme, since the readme defers installation to it, and note the two replace directives in go.mod, which are commented out and point at sibling checkouts of core and share.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. Project website
4. README
5. unitedrhino/things on GitHub