iot-master: a Go IoT gateway whose plugins talk over MQTT

A gateway that is one program file, plus an Angular console

IoT Master is described as an open source, free IoT data platform, and the README positions it as different from a traditional IoT platform by being written in Go. The listed advantages are concrete rather than promotional: a single program file that needs no installation, a minimum memory requirement of 12 MB, a plugin mechanism for extending functionality, support for multiple operating systems and processor architectures, Lua scripting to extend protocols, JavaScript scripting for edge computation, support for smart home scenarios with scheduled and linkage control, and WebRTC peer to peer video transmission.

The functional scope covers the usual middle of the industrial IoT stack: data collection, formula calculation, timed control, automatic control, exception alarms, flow monitoring, web configuration screens and remote debugging.

The repository itself is larger than a single program. The Go side is main.go plus directories named iot/, plc/, protocols/, pkg/ and apis/, and the front end lives in src/ and pages/ with public/ and www/ for static assets, and there is a weixin/ directory for the WeChat integration and a history/ directory. The build is a build.sh script, .goreleaser.yml handles the releases, and there is an iot-master.yaml.bak configuration file and a menu.json that presumably drives the console navigation.

The project is maintained by a company, Nanjing Zhengge Intelligent Technology, and the README gives a company link, an email address and a phone number, with the homepage at zgwit.com. The repository listing records the primary language as JavaScript, which reflects the size of the front end rather than the nature of the system, since the backend is Go 1.25 and the module is github.com/god-jason/iot-master.

Releases are regular: v0.6.0 on 2025-12-03, v0.6.2 on 2026-01-10 and v0.7.0 on 2026-04-10, and the last push was on 2026-07-09.

The MQTT topic tree is the plugin contract

The most useful part of the README for a developer is the MQTT topic specification, because it is the interface between the core and every plugin, and between plugins and anything else you want to build against the platform.

Plugins communicate with each other over an MQTT bus, and the topics are organised into families. The connection family is scoped by a linker name and a link id, and the linker names given in the README are the transport types, serial, can, tcp-client, tcp-server, udp-client, udp-server, udp-group and gnet-server. Under it, opening a connection carries a JSON options object with a remote address, closing carries nothing, and data moves up and down as raw binary.

The protocol family sits above that, scoped by protocol name, linker name and link id, and the messages are where the actual device interaction happens: poll, sync, read, write and action, each carrying a message id and the device identifiers involved. The README notes that a device change is done as a delete followed by an add, and that data is sent down through the link family's down topic rather than through the protocol topic directly, which keeps the transport layer separate from the protocol layer.

The remaining families are for state rather than commands. The product family carries the product configuration and the product model, the device family carries property values, read and write requests with their responses, events with a title, message and level, and actions such as a reboot. There are project and space families for grouping, and a separate exception family where a pushed message carries the user id, the device id and the event.

All of it is plain topic strings:

`link/${linker_name}/${link_id}/#`
`protocol/${protocol_name}/${linker_name}/${link_id}/#`
`product/${product_id}/#`
`device/${device_id}/#`

Because the contract is MQTT topics and JSON payloads, you can write a plugin in any language with an MQTT client, and you can read the whole system with an MQTT subscriber, without going through the Go code at all. That is the most attractive property of the design.

The protocol checklist is honest about what is missing

The repository includes a support checklist for protocol libraries, and it is a checklist with tick boxes in both states, which is more informative than a feature list.

What is implemented includes Modbus RTU and Modbus TCP, three PLC families, namely Siemens S7 with fetchwrite, mpi and ppi, Mitsubishi melsec, and Omron fins and hostlink, and two Chinese metering standards, DL/T645-1997 and 2007 for multifunction electricity meters, and CJ/T188-2004 and 2018 for residential metering instrument data transmission. Modbus ASCII is explicitly not planned, on the grounds that it is rarely used.

What is not implemented is the longer list. Other PLC families, namely AB df1, Delta dvp, Keyence melsec, Panasonic melsec and newtocol, Fuji spb and Fatek, are all unchecked. The building automation protocols BACnet and KNX are unchecked. So are the power system protocols IEC 101, 103 and 104, IEC 61850, the Chinese power grid protocol DL/T698.45-2017, and a group of water and water resources telemetry standards, SL/T427-2021, SL/T651-2014, SL/T812.1-2021 and SZY206-2016.

The distinction in that list is worth reading carefully for an industrial deployment. A checklist of what is missing tells you which conversations you are going to have with a device vendor before you buy anything, and the standard names are precise enough to be asked about directly. A tool that claims to speak every protocol usually means it speaks a small subset of them well.

For a shop that standardised on Modbus or on one of the three supported PLC families, this is a workable list. For a building with BACnet devices or a utility with IEC 61850 equipment, it is not, and no amount of Lua extension changes that without writing a driver.

The Go dependency list explains the architecture

The go.mod file is long, and picking out the entries that carry design decisions is faster than reading all of it.

The MQTT layer is doubled, and deliberately so. github.com/eclipse/paho.mqtt.golang is the client, and github.com/mochi-mqtt/server/v2 is a broker implemented in Go, which means the platform can embed its own broker rather than requiring an external one. Everything else in the system, the plugins, the console and any external tool, talks to that broker over the topic tree described earlier.

The scripting story is in the JavaScript engine. github.com/dop251/goja and its nodejs companion are a JavaScript runtime in Go, which is what makes the README's claim of edge computation with JavaScript scripts possible, and it is also what lets a plugin be extended without recompiling the gateway.

The rest of the list maps onto the feature set. gin and its cors, gzip, pprof and sessions middleware are the web stack, viper and pflag are configuration and flags, gocron is the scheduler behind the timed control and the smart home scenarios, and ants is the worker pool that sits between the broker and the device traffic. Storage is xorm with a MySQL driver for the operational data, and there is an InfluxDB client for the time series side. Logging is logrus with lumberjack for rotation, and gopsutil for system metrics. kardianos/service is a cross platform service wrapper, and gorilla/websocket covers the browser connection.

Two dependencies point at features that are easy to miss. The PowerWeChat module is the WeChat channel, which explains the weixin/ directory in the tree. The coordinate and geohash libraries, together with a coordinate conversion helper in the front end dependencies, are for mapping, and the front end also loads the Amap JavaScript API, so the platform handles the coordinate system differences that Chinese mapping services require.

The front end is a separate project in the same repository, named boat-ui in the package manifest, built with Angular 21 and ng-zorro-antd, with ECharts through ngx-echarts for the charts, an MQTT client for the live views, CodeMirror for editing configuration, marked for the Markdown rendering, and a SheetJS build for spreadsheet export.

The licence note and the GPL text do not agree

The repository is released under GNU GPLv3, and the README points at the LICENSE file. Underneath that, in the same section, there is an additional note in Chinese saying the product is for personal free use only and that commercial requirements should be handled by contacting the maintainers.

That is a tension a careful reader should not gloss over, and this is not legal advice. GPLv3 grants broad rights, and a restriction that limits use to personal, non-commercial purposes sits awkwardly with the copyleft terms the project also claims. A company evaluating the platform for a production line, and a vendor considering embedding it in a product, should read the LICENSE file and the note together and get a written answer from the maintainers before deploying it.

The other point about the licence is scope. The project is not just the Go binary: the tree contains the Angular front end, the protocol drivers, the Lua and JavaScript extension mechanisms and the console, and the front end alone pulls in a large dependency set with its own licences. A GPLv3 deployment therefore has a reach that includes the whole tree.

On the maintenance side, the record is a project with regular tagged releases and a gap between the last release and the last push. v0.7.0 landed on 2026-04-10, and the last push was on 2026-07-09, which is the date to keep in mind when you are planning an upgrade rather than a version in the 0.6 range. The topic list includes xorm, mqtt, plc, scada, hmi, opc-ua and the individual protocol families, which is a fair summary of the scope, with opc-ua listed as a topic even though the protocol checklist in the README does not mark OPC UA as supported.

Editorial conclusion

Adopt iot-master if you need to collect data from Modbus equipment or from Siemens, Mitsubishi and Omron controllers and want the gateway to be a single program file that runs on modest hardware, since the README quotes a minimum memory of 12 MB and a plugin model that needs no installation. Do not adopt it if you need BACnet, KNX, IEC 61850 or the Chinese power and water telemetry standards, because the repository's own checklist leaves those unchecked, and do not adopt it for commercial use without reading the licence terms first, because the README adds a note restricting the product to personal free use on top of GNU GPLv3. Before you plan a deployment, confirm which protocol your devices actually speak, and check the MQTT topic tree, because that contract is what your own plugins and your own tooling have to implement.

Frequently asked questions

Official sources

1. god-jason/iot-master on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases