DEV Community: manthink

The Five-Layer Funnel for LoRaWAN Troubleshooting: From "No Data in the Cloud" to "The Numbers Are Wrong"

manthink — Mon, 02 Nov 2026 07:59:41 +0000

Currency note: figures in this article are converted at the October 2026 reference rate of 1 USD ≈ 6.71 CNY and 1 EUR ≈ 7.88 CNY. Original quote currencies are preserved; CNY amounts are conversions.

The most expensive thing in a troubleshooting session is not a missing tool. It is guessing.

The symptom is one sentence: "The device is offline." That sentence can mean five completely different things. The gateway lost power. The gateway is online but hears no radio frames. Frames arrive but decryption fails. Decryption succeeds but the parser errors out. Parsing succeeds but the data never reaches storage or the outbound channel.

These five causes live in five different layers. They require different tools, different screens, and different evidence. Without an order, troubleshooting degenerates into refreshing every page once and then changing whichever setting looks most suspicious — then finding it did not help, then trying the next one.

The funnel replaces guessing with elimination. Each layer answers exactly one question. Yes moves you down; no stops you there. Five layers in, the fault is pinned to a single cell. No luck required.

1. The funnel at a glance

Layer	Question to answer	Where to look	Key criterion
1	Is the gateway online	Operations → Gateway Management	Whether online status, heartbeat time, and total online time agree
2	Did the gateway hand frames to the NS	Network Data → NS Data	Whether records can be found by DevEUI or DevAddr
3	Did the NS decrypt successfully	Network Data → AS Data	Whether an application-layer packet exists at the same moment
4	Did the thing model parse it	Application Data → Realtime Data / Device → Telemetry	Whether values and timestamps are advancing
5	Where did the parsed data go	Forward whitelist, raw retention switch, subscriber	Dropped, filtered, or never subscribed

The third column of each row is more important than it looks: what a false conclusion at this layer costs you. Most troubleshooting disasters are not caused by missing a symptom. They are caused by seeing a symptom, attributing it to the wrong layer, and breaking a configuration that was fine. The classic version: turning off ADR to "make data come up faster," and blowing the power budget of a battery device in the process.

2. Layer 1: Is the gateway online

Open Operations → Gateway Management. Each row shows location, type, online status, enabled status, hardware version, firmware version, LoRa standard, total online time, heartbeat time, and update time.

Most people read the online status column only. That is the most deceptive column on the page.

Read the three time fields together

Heartbeat time: when the gateway last reported a heartbeat
Total online time: cumulative time online
Update time: when this record was last modified

A gateway can show "online" while its heartbeat time stopped forty minutes ago. The default heartbeat period is 60 seconds. Forty minutes without a heartbeat means it has done nothing for forty minutes — the platform simply has not met the condition to mark it offline yet. Being marked offline requires a time condition to be satisfied; it is not a "last message received" flag.

Conversely, a very short total online time with an advancing heartbeat time means the gateway is repeatedly dropping and reconnecting. That is the signature of a power or network problem, not a radio problem.

Criterion: the gap between heartbeat time and now should be smaller than twice the heartbeat period. If the gap is larger while the status still reads online, stop trusting that column and read the heartbeat time.

Three definitions of "online," not interchangeable

This has to be settled before anything else. ThinkLink exposes at least three different online signals with different algorithms and different boundaries:

Source	Algorithm and boundary
API `online` field	Treated as online when heartbeat is empty; when non-empty, computed from activity time and twice the heartbeat, missing activity time counts as offline, and an exactly-equal deadline no longer counts as online
`server_attrs._online`	Numeric 1 online, 0 offline; with an empty heartbeat and the feature enabled it stays 1 with no timeout task; with a non-empty heartbeat it only goes offline when the current time strictly exceeds `active_time + 2 × heart_period`
MQTT `data.online`	A boolean state-change notification; asynchronous propagation has latency; it is neither a full state snapshot nor an alarm event

Each path gets used somewhere: dashboard display, statistics, automation. Mixing them produces a very concrete failure. Your dashboard reads server_attrs._online, your alarm rule reads API online, the two disagree, and you conclude the data is wrong — when in fact only the definitions differ.

One more trap: after offline notification is disabled, _online retains its last value. A leftover 0 or 1 is not evidence of the current state. Reading 1 and concluding the device is alive is wrong.

If the gateway is offline, separate "no power" from "no network"

Three platform-side checks:

Ping: one of the dedicated operations for ManThink-type gateways, confirming reachability of the platform-to-gateway path
Edit → IP address: the gateway reports its current IP when it comes online; this field lets you confirm its real network address and detect a changed IP or a move to another subnet
Status trend: shows the online/offline curve over a chosen range so you can locate when the drop started. Its value is separating "always dropping" from "started dropping at time X" — the latter lines up directly with construction work, power cuts, lightning, or hardware swaps

If Ping fails and the IP is stale or empty, the problem is on the gateway side or on the path to the server, not in the platform. Adjusting platform settings at this point is wasted effort.

3. Layer 2: Did the gateway hand frames to the NS

This is Network Data → NS Data. You are looking at raw LoRaWAN frames together with frequency, RSSI, SNR, and data rate.

The decisive detail is which identifier you search with. Get this wrong and you will conclude "the NS received nothing" when it received plenty:

Situation	Search field	Why
Device has never joined, or was just reset	DevEUI	Join Request / Join Accept frames are identified by DevEUI; no DevAddr exists yet
Device has joined and reports normally	DevAddr	After joining, all data frames use a dynamically assigned DevAddr, never the DevEUI

A factory-fresh device returns nothing for its DevEUI and nothing for its DevAddr — it has no DevAddr yet. A healthy running device returns nothing for its DevEUI on ordinary uplinks, because those frames carry the DevAddr. Neither empty result is a fault. Both are a search on the wrong key.

Criterion: NS has data → the problem is above the NS (start at layer 3). NS has no data → the problem is radio or backhaul, not the platform.

When NS has no data, the directions are:

Is the device even transmitting (device-side log via serial or vendor tool)
Are the frequencies right (device channel plan versus gateway regional standard)
Distance and obstruction (RSSI and SNR — but only meaningful once at least one frame arrives; with zero frames there is no signal to read)
Is the gateway backhaul working (whether UDP 1700 is open — covered separately below, it is the single most common trap)

4. Layer 3: Did the NS decrypt successfully

This is Network Data → AS Data. AS data is what the NS emits after decrypting and deframing the LoRaWAN frame: LoRaWAN encryption is gone, but userdata.payload is still the Base64-encoded application payload, not yet parsed by the thing model.

This layer carries the most diagnostic information of the five. An AS uplink looks like this:

{ "if": "loraWAN", "type": "data", "moteeui": "6353012af1090498", "version": "3.0", "gwrx": [ { "eui": "5a53012501030056", "chan": 0, "lsnr": 14.2, "rfch": 0, "rssi": -21, "time": "2025-09-24T07:07:03.807677Z", "tmst": 1152383989 } ], "moteTx": { "codr": "4/5", "datr": "SF7BW125", "freq": 470.9, "modu": "LORA" }, "userdata": { "port": 11, "class": "ClassA", "seqno": 27464, "payload": "IQcDDG4BAADaBB0C538J", "confirmed": false } }

Every field has a specific diagnostic job:

Field	Diagnostic use
`moteeui`	Confirms which device sent it, ruling out a mistyped EUI
`gwrx[]`	Every gateway that heard the frame, with per-gateway RSSI / LSNR. With multiple receivers, take the best RSSI as the link-quality reference
`gwrx[].chan` / `rfch`	Channel number and RF chain. Misconfigured frequencies surface here
`gwrx[].lsnr` / `rssi`	SNR and signal strength. SNR is the real LoRa margin metric; RSSI is only a reference
`moteTx.datr`	Data rate, e.g. `SF7BW125`. If ADR is broken, this sticks at the lowest rate
`moteTx.freq`	Uplink frequency. A mismatch with the gateway channel plan is a frequency problem
`userdata.port`	FPort, distinguishing business channels
`userdata.seqno`	Device frame counter. This is how you diagnose retransmission and loss — contiguous counters with uneven spacing mean retries; gaps mean real loss
`userdata.payload`	Base64 application payload; exactly what the thing-model script consumes

NS has data, AS is empty: only three possibilities

The official decision table is refreshingly blunt:

Symptom	Likely cause	Action
NS has data, AS empty	LoRaWAN key mismatch (AppKey / AppSKey / NwkSKey)	Verify the keys in the profile against what is burned into the device
NS has data, AS empty	No device profile, or `enable` is false	Create the profile and confirm `enable` is on
AS has data	Decryption succeeded; go to layer 4	—

The "enable is false" case is especially sneaky. It raises no error. The NS simply does not respond, which from the outside is indistinguishable from a wrong key. And it is a silent switch: the profile exists, the keys exist, nothing takes effect.

One more easily missed constraint: a given device profile should be enabled on exactly one platform (Cloud / TKG / TKE) at a time, otherwise join conflicts follow. A profile left enabled in the cloud while the device is also commissioned into an edge server means two NS instances competing for the same DevAddr. The symptom is "works, then does not, then works" — far harder to chase than a clean failure.

FPort is more than a business category

Several FPorts are conventional on the platform:

FPort	Purpose
51	Pass-through: raw bytes forwarded as-is
201	Firmware OTA
209	Heartbeat, used to confirm device liveness
214	Parameter configuration and readback

A packet on port 209 is a heartbeat, not business data — its payload contains none of your measurement points. A thing-model script without a per-port branch will happily parse a heartbeat as sensor data and emit nonsense. This is a common source of "one field occasionally turns into a weird number."

5. Layer 4: Did the thing model parse it

Two entry points: Application Data → Realtime Data, and Device detail → Telemetry tab.

Telemetry in the device detail is grouped by thing model and shows every field from the most recent parse together with a timestamp. It updates by MQTT push, so no manual refresh is needed. That makes it a good liveness probe: stare at it for three minutes. If neither values nor timestamps move, parsing has stopped. If the timestamp advances but a specific field is empty, that field is simply never assigned by the script.

AS has data, realtime data is empty: only two causes

Symptom	Likely cause	Action
AS has data, realtime empty	No thing model bound to the device	Bind one in model management
AS has data, realtime empty	Parser script error	Open the editor and feed the AS payload in manually to debug
AS has data, some fields empty	Script does not cover that FPort or field	Inspect the branch for that port

That middle row — manually feeding the payload — is the highest-leverage action in the entire troubleshooting system. Script errors, a null return, a wrongly shaped object: in the overwhelming majority of cases you can reproduce them by pasting a Base64 string. No site visit, no restart.

Three fixed traps in the script layer

Three things reliably produce "it will not parse":

First, the only output channel is the return value. Scripts run in a restricted sandbox: no console.log, no async, and a 1000 ms execution ceiling. Every result, every diagnostic, must come out through return. Anyone expecting print-based debugging sees "nothing was output" and wrongly concludes "the script never ran."

Second, the payload comes from msg.userdata.payload and it is Base64. Treat it as a string and you get mojibake instead of bytes. Decode it first, then read by byte offset.

Third, a script existing does not mean the mapping is done. Written, saved, no error — none of that proves the field reached telemetry. The only proof is a value visible in the Telemetry tab. These are separate states on the platform, and conflating them produces endless loops between "but I wrote it" and "but there is no data."

6. Layer 5: Where did the data go

At this point AS has packets and telemetry has values, yet downstream still says it received nothing. The problem is no longer acquisition. It is the data egress.

Egress 1: the raw retention switch

One easily misread symptom: the AS Data page is empty while telemetry is perfectly fine.

This is not a contradiction. Raw packet retention must be enabled separately via the device's real_time_storage switch. When it is off, the NS still receives, decrypts, runs the thing model, and writes telemetry — the whole chain works — it simply keeps no raw copy at that layer.

So "nothing on the AS page" has two entirely different meanings: no signal came in, or signal came in but was not archived. The discriminator is trivial — check whether telemetry has values. Values present means retention is off. No values means a link problem.

Egress 2: the forward whitelist

Since 2.00.066, server attributes and shared attributes are not forwarded by default; only fields explicitly checked for forwarding are sent. The intent is to keep irrelevant fields from flooding MQTT, but the side effect is: you add a server attribute, see a value in the UI, and the MQTT side never receives it — because it was never checked.

Similarly, when the target broker disconnects there is no buffering and no replay, and no exactly-once guarantee. A forwarder is not a message queue; it is a realtime channel. Data produced during those few minutes while the subscriber restarts is simply gone.

Egress 3: the subscriber's own problems

The most common sentence on the MQTT side is "I subscribed but there is no data." Three fixed causes:

{tenant} was never replaced with the organization account. Topics look like /v32/{tenant}/as/up/data/#, where {tenant} is a placeholder, not a literal. Copy it verbatim and you connect fine, subscribe fine, and receive nothing
Subscribed to the parsed topic while the device has no forwarding configured. tkl/up/telemetry/# is parsed; as/up/data/# is raw. They draw from different sources, and data on one says nothing about the other
Received, then dropped by a script. A forwarding script that returns null discards the message. That is the correct way to filter, and also the most common invisible failure

One version note worth remembering: registering a subscription is not the same as subscribing successfully — only a SUBACK counts. Since 2.00.070 this semantics is explicit, yet in the field many still treat "shown as configured in the UI" as "receiving data."

False empties introduced by paginated loading

Since 2.00.075, configuration, attributes, and telemetry load separately on demand. After switching tabs, wait for a successful load before editing and saving — unloaded fields must not be treated as empty values. MQTT messages may likewise carry only a subset of whitelisted attributes; receivers should merge by field rather than overwrite whole groups.

Together these two facts produce an awkward class of failure: a save writes an empty value into a field that had simply not loaded, or a receiver overwrites complete state with a partial message. The visible symptom is "a setting reverted itself," and it is hard to reproduce.

7. The on-site trio: diagnosing without the platform

The platform answers "which layer is broken." The field answers "why is that layer broken." Three things are enough.

One: the gateway's local web console

GD6 series gateways use the gwTool6 web console. Key entry points:

Ethernet defaults to DHCP; on the same subnet, browse straight to the gateway IP
The Wi-Fi AP SSID is GD6-<Gateway EUI>, falling back to LGW-Config only when no valid EUI exists
Factory AP password and web password are both wifi!0804, managed independently; change them on first login

With no network on site, joining that hotspot from a phone is the fastest route into the console. Note the condition: the hotspot must actually appear and accept connections to count — "shown as enabled in the UI" does not.

The Radio page frequencies, the NS page server address and ports, and the "save and restart to apply" confirmation all live here. One operational detail deserves writing down: the "submit" button at the bottom of the page is what saves Radio, whereas the NS page uses "save and restart," and after the service recovers you must reload to verify. Skip the reload and you are reading the form's old values, not the device's current ones.

While on the subject, one boundary specific to GD62: it has no external REC button. Any "hold REC for about two seconds" recovery procedure does not apply to that unit. Factory reset goes through the support procedure; afterwards the web password returns to wifi!0804 while a previously written Gateway EUI is retained.

Two: an MQTT client

Whether mosquitto_sub, MQTTX, or your own script, subscribing once to /v32/{tenant}/as/up/data/# shows you every device's raw uplink directly. It is the fastest way to answer "is anything actually flowing," much faster than paging through the UI.

Watch three things: whether packets appear at all, whether moteeui is the device you care about, and whether userdata.seqno advances contiguously. That last one instantly separates "the device never sent" from "the device sent and it never arrived."

Three: a site visit you can actually price

Troubleshooting time has a quantifiable cost. A single site visit (labour plus travel) runs roughly 300–800 CNY in a tier-one Chinese city, and roughly 150–400 USD (≈ 1,000–2,700 CNY) overseas at published service rates. The point is not precision. The point is that it puts a price on "can this be solved remotely": if a problem can be walked through all five layers remotely and pinned to one layer, the site visit becomes "go replace that part" instead of "go see what is wrong." The difference in elapsed time is typically half a day versus three days.

The more expensive failure is misattribution. Disabling ADR to "make data come up faster" will blow a battery device's power budget within a week. Nothing shows on site. Three months later it surfaces as "the batteries do not last," and by then it is very hard to trace back to which setting changed.

8. Seven traps from real integration work

These seven come from actual integration records, not theory. Their common shape: the symptom appears in the platform, the root cause sits outside it.

Symptom	Root cause	Fix
No gateway UDP arrives at all	Security group allows TCP only; UDP 1700 not opened	Add an inbound rule for UDP 1700
Gateway packets rejected (illegal / single byte)	Not using Semtech UDP, or a proprietary protocol	Set `nsProtocol` to `pkt_fwd`
Packets received but nothing goes uplink	Leading space in `nsAddress`	Remove the space and restart the service
Gateway connects but frames are dropped	Bridge prefix (region) does not match the device band	Point the topic template at the correct sub-band
Events on a third-party platform, no telemetry in ThinkLink	Forwarder MQTT subscription silently dies after restart	Re-save the forwarder to force a resubscribe
Uplink jitter and frequent retransmission	Profile wrongly set to Class C + ADR + DevStatusReq, sending surplus downlinks to a battery-powered Class A device	Set the profile to Class A, disable ADR and DevStatusReq
AS Data page empty but telemetry normal	Raw retention switch not enabled	Enable `real_time_storage` on the device

The first one deserves its own paragraph. UDP 1700 is the highest-frequency trap in all of LoRaWAN troubleshooting, and the easiest place to fail at "I am sure I configured it" — because local testing usually has no security group at all, and the problem only appears after moving to cloud. The same logic appeared in issue 24 on BACnet: the Docker inbound port list does not include 47808 or 502, and the installer neither maps nor allows them, producing "the platform says the service is running, the other side cannot even scan it." Always audit the port list separately. Never trust installer defaults.

The fifth trap belongs to the same family: the connection is up, the process is alive, the configuration is correct, and no data arrives. There is no error to read; the only test is "re-save it and see whether it recovers." It is a reminder that running and working are two different states.

9. Compressing the funnel into 20 minutes

A real session does not require visiting every page. Work in time boxes:

0–3 min: confirm the gateway. Compare heartbeat time against now; check whether total online time has grown steadily over a long period. Ping once. If the gateway is offline, layers 2–5 are irrelevant.

3–8 min: confirm frames arrive. On NS Data, search with the right key: DevEUI before join, DevAddr after. Finding it means radio and backhaul both work and the problem is above; not finding it sends you straight to frequencies and ports.

8–13 min: confirm decryption. Search AS Data with the same identifier. Frames but no packets means the key or the profile's enable flag — those are the only two options.

13–17 min: confirm parsing. Read Realtime Data and the device Telemetry tab together. An advancing timestamp means it is alive; if not, paste the AS payload into the script editor and run it by hand.

17–20 min: confirm egress. Telemetry has values but downstream does not: check real_time_storage, whether the forward whitelist boxes are ticked, and whether {tenant} was substituted in the subscriber's topic.

Twenty minutes, and the fault lands on a specific criterion. What remains is fixing, not finding.

10. What this method actually solves

The tools are unremarkable: five screens, one MQTT client, one gateway web console.

What is not unremarkable is the order. The same five screens read in the right order are elimination. Read in the wrong order they are sampling. Sampling conclusions depend on luck, and luck is never sufficient on a fault site.

There is a secondary benefit. When you know exactly what proves each layer, you also know which observations cannot serve as conclusions. "Online" does not prove working. "Configured" does not prove running. "The script exists" does not prove the mapping is done. "There is a value on the page" does not prove the data was sent. Each of those four sentences maps to a specific trap described above.

The ceiling on troubleshooting skill is rarely about how many tools you know. It is about knowing which evidence does not count as evidence.

Official documentation

Gateway Management: https://www.think-link.net/docs/en/Maintenance/GatewayManagement.html
Device Management: https://www.think-link.net/docs/en/Maintenance/DeviceManagement.html
NS Data: https://www.think-link.net/docs/en/Data/NetworkData/NSData.html
AS Data: https://www.think-link.net/docs/en/Data/NetworkData/ASData.html
ThinkLink Protocol: https://www.think-link.net/docs/en/Protocol/ThinkLinkProtocol.html

LoRaWAN Gateway Antenna Selection and Installation Guide: Why 3 dBi Sometimes Beats 8 dBi

manthink — Wed, 28 Oct 2026 09:37:38 +0000

Currency note: USD figures are quoted as originally published. Reference conversion for October 2026: 1 USD ≈ 6.71 CNY. Prices marked "reference price" are subject to the manufacturer's current quotation.

Two LoRaWAN projects, less than three kilometres apart, using the same gateway model, the same batch of meters and the same ThinkLink tenant. One reaches a basement water meter 2.4 km away with -118 dBm and -12 dB still in hand. The other starts dropping packets 300 m away inside a single building — and went back to site three times.

The difference was not the gateway and it was not the platform. One project put the antenna on a ten-metre mast on the roof with the stock 3 dBi omnidirectional whip. The other bought a "higher gain" 8 dBi antenna and screwed it onto a server cabinet — a metal cabinet, with the base of the antenna buried in a cable tray.

The antenna is the part of a LoRaWAN deployment most often treated as an accessory, and it is the one variable in the link budget that routinely moves it by 10 dB. Gateway transmit power is fixed: GD73 is rated at a maximum of 27 dBm for the -1 suffix and 22 dBm for the -2 suffix (±2 dBm deviation); GD61x and GD62 are 22 dBm maximum for the -2 suffix. Receiver sensitivity is fixed too: these gateways are all specified at -141 dBm (SF12, BW 125 kHz). If both ends of the budget are given, where do the remaining decibels come from?

From the antenna, and from where you put it. This article works through the numbers.

1. Start with the band: the wrong antenna is the first line on the trouble ticket

Official frequency ranges for ManThink gateways:

Region	Frequency range
CN470	470–510 MHz
EU433	433–434 MHz
EU868	863–870 MHz
AS923	920–928 MHz
US902 / US915	902–928 MHz
AU915	915–928 MHz

The documentation states three hard constraints about antennas, and the wording is worth quoting verbatim:

GD61x user guide, step 4: "Confirm the antenna frequency band matches the gateway's regional version."
Note under the GD62 (IP67) specification table: "The RF region must be consistent with the hardware, antenna and end-device configuration."
GD62 pre-installation notes: "Connect the LoRa antenna before powering on. Do not start LoRa transmission with no antenna connected."

These cover three different things.

The first is that the antenna's own frequency range must cover the region the gateway operates in. A whip marked 433 MHz connected to a CN470 gateway is off resonance by roughly 40 MHz, and the VSWR collapses accordingly.

The second is system-level consistency: the gateway's RF hardware version, the antenna and the end devices must all sit in the same region. The mistake usually happens in procurement — a project specified for CN470 ships with an EU868 unit, and nobody notices until nothing joins. The symptom looks exactly like a broken antenna.

The third is a safety constraint, and it is the one installers skip most often: never transmit with no antenna connected. Almost all of the front-end output power reflects back into the power amplifier, and the output stage of a concentrator like the SX1301/SX1302 is not designed to absorb it. "Gateway powered up and never demodulated another packet again" traces back to exactly this — mains plugged in before the antenna was tightened.

So step one is not comparing parameters. Step one is checking: the RF region on the rating plate, the frequency range printed on the antenna label, and the regional configuration on the end devices. All three must agree before anything else happens.

2. Three things that matter more than the gain number

An off-the-shelf LoRa antenna label usually shows gain, VSWR, polarization and connector type. Buyers look at the first line. The other three decide whether the deployment works.

The unit trap: dBi vs dBd

Antenna gain uses one of two reference bases: dBi references an ideal isotropic radiator, dBd references a half-wave dipole. The conversion is fixed:

0 dBd = 2.15 dBi
dBi value = dBd value + 2.15

The same physical antenna labelled 5 dBi or 2.85 dBd is the same antenna. Compare two products without normalising units and you invent 2.15 dB out of nothing — which, by the worked example in section 4, is roughly 18% of coverage radius appearing and then disappearing again.

Gain is not amplification, it is redistribution

This has to be understood before any selection is made. A passive antenna generates no energy; gain comes from concentrating radiation into preferred directions at the expense of others. For an omnidirectional antenna, that means flattening the vertical lobe, paid for with nulls directly above and below the antenna.

A 2 dBi omnidirectional antenna typically has a vertical half-power beamwidth of 60–80 degrees. Push it to 6–8 dBi and that may drop to 15–25 degrees. This is the physical reason behind "high-gain antenna on the roof, nothing works on the floor below" — the antenna is doing exactly what it was designed to do, which is send energy to the horizon.

Indoor scenarios are worse. A gateway antenna flush-mounted to the ceiling of a 3 m machine room, with end devices spread from basement to third floor, will favour the middle floor with a high-gain whip while the top and bottom get weaker than they would with a 2 dBi one.

VSWR measures how much energy never leaves

VSWR describes the impedance match between antenna and feeder. Ideal is 1.0. The usual engineering reading is:

VSWR	Reading	Return loss	Mismatch loss
≤ 1.5	Good	≥ 14 dB	≤ 0.18 dB
1.5 – 2.0	Acceptable	9.5 – 14 dB	0.18 – 0.51 dB
2.0 – 3.0	Investigate	6 – 9.5 dB	0.51 – 1.25 dB
> 3.0	Fail	< 6 dB	> 1.25 dB

Note the last column: even at a VSWR as poor as 3.0, the power actually wasted is only 1.25 dB. The mismatch loss itself is rarely what kills you. What kills you is what a high VSWR reveals — the antenna is not resonant anywhere near the band you are using. That is where the missing fifteen decibels went.

Antennas for low bands such as 470 MHz are physically large, and many products are electrically shortened to fit, which narrows bandwidth and reduces efficiency. This is why you select by regional band rather than buying a generic "LoRa antenna".

Polarization: twenty dB or more, silently

LoRaWAN end devices and gateways normally use linear polarization, installed vertically by default. If a device antenna is laid sideways inside an enclosure, or a meter is mounted on its side in a pit, the polarization plane rotates.

Polarization mismatch loss follows a cosine-squared relationship: roughly 3 dB at 45 degrees, about 10 dB at 70 degrees, and approaching full loss at 90 degrees — in practice a 20 dB-plus drop. It is notoriously hard to diagnose, because "the device loses packets ten metres directly below the gateway" appears to make no sense at all until you stand the device upright and it works.

3. The link budget: account for every decibel

Selection by feel is a gamble. This is arithmetic. The power balance for an uplink is:

Received power = device Tx power + device antenna gain − path loss − obstruction loss − feeder loss − connector loss + gateway antenna gain

Solving the inequality gives the maximum allowable path loss:

Allowable path loss = device Tx power + device antenna gain + gateway antenna gain − gateway sensitivity − feeder loss − connector loss − obstruction loss − design margin

Every term is measurable or documented. Fill them in one by one.

Free-space path loss

FSPL (dB) = 32.44 + 20·log₁₀(distance in km) + 20·log₁₀(frequency in MHz)

Free-space loss at three common LoRaWAN bands:

Distance	470 MHz	868 MHz	915 MHz
1 km	85.9 dB	91.2 dB	91.7 dB
2 km	91.9 dB	97.2 dB	97.7 dB
5 km	99.9 dB	105.2 dB	105.7 dB
10 km	105.9 dB	111.2 dB	111.7 dB

Note the frequency term: at the same distance, 470 MHz loses 5.8 dB less than 915 MHz. That is the natural advantage of the lower Sub-GHz band, and the reason CN470 deployments often show better coverage than US915 ones at equal power — not better hardware, just physics.

Real environments replace n

Free space assumes a path loss exponent of n = 2. Practical values:

Environment	Path loss exponent n	Loss per doubling of distance
Free space / clean line of sight	2.0	6 dB
Suburban / open campus	2.5 – 3.0	7.5 – 9 dB
Built-up urban	3.0 – 3.5	9 – 10.5 dB
Dense indoor	3.5 – 4.5	10.5 – 13.5 dB

Applied on top of the 1 km reference:

PL (dB) = FSPL(1 km) + 10·n·log₁₀(distance in km) + obstruction loss

A worked example

Scenario: CN470, an open campus with mostly outdoor installations. A GD73 (-2 suffix, 22 dBm) with a 3 dBi omnidirectional antenna at the top of a ten-metre mast. Gateway side: 1.5 m of LMR-400 plus two connectors. End device: a KC11 DTU transmitting at 14 dBm with a 0 dBi stub, inside an outdoor meter box. Target SF12, BW 125 kHz, gateway sensitivity -141 dBm.

Gateway-side losses line by line:

Item	Value	Note
Feeder, LMR-400 @ 470 MHz, 1.5 m	0.13 dB	≈ 0.09 dB/m
Two connectors	0.40 dB	≈ 0.2 dB each
Gateway-side total	0.53 dB	count as 0.6 dB

Maximum allowable path loss:

14 dBm (device Tx) + 0 dBi (device antenna) + 3 dBi (gateway antenna) − (−141 dBm) (gateway sensitivity) − 0.6 dB (feeder and connectors) − 20 dB (box penetration and clutter) − 10 dB (design margin)
= 127.4 dB

Back-solving distance at n = 3.0:

85.9 + 30·log₁₀(d) ≤ 127.4
log₁₀(d) ≤ 1.383
d ≤ 24 km

Which is obviously larger than any real campus deployment. Section 5 explains why. The point here is this: the power budget is inherently generous, which means the real constraint on LoRaWAN coverage is almost never transmit power — it is antenna placement and environment.

4. Feeder cable: the easiest 3 dB to throw away

In the example above the feeder accounted for only 0.6 dB, because it was LMR-400 and only 1.5 m long. Change one of those two things and the picture changes quickly.

Typical coaxial cable attenuation in the Sub-GHz range:

Cable type	@ 470 MHz	@ 900 MHz	Total over 3 m @ 470 MHz
RG-58	≈ 0.35 dB/m	≈ 0.57 dB/m	≈ 1.05 dB
RG-213	≈ 0.20 dB/m	≈ 0.32 dB/m	≈ 0.60 dB
LMR-400	≈ 0.09 dB/m	≈ 0.13 dB/m	≈ 0.27 dB
1/2" corrugated copper feeder	≈ 0.02 dB/m	≈ 0.03 dB/m	≈ 0.06 dB

Add connectors at roughly 0.1–0.3 dB each in this range, counting an adapter (N-type to SMA, say) as two.

All small numbers. Two observations follow.

First, feeder loss applies in both directions. Ten metres of RG-58 costs 3.5 dB on receive and another 3.5 dB on transmit. That is why "keep the gateway in the rack and run a long feeder up to the roof" is a bad plan — you lose 3.5 dB at each end, roughly 55% of the power in each direction.

Second, remember what 3 dB is. It is half the power. A cheap ten-metre run can take a 22 dBm radio down to well under half its effective radiated output. The care you put into choosing antenna gain is easily wiped out by the cable you saved money on.

There is only one correct engineering answer: move the gateway closer to the antenna, not the feeder closer to the antenna. A device like the GD62 (IP67), rated for -25 °C to 60 °C with IP67 protection, was designed to be mounted on a pole. Put the antenna on the chassis connector with a short jumper, and run Ethernet/PoE back to the rack — 100 m of Ethernet costs nothing in RF terms, 10 m of feeder costs decibels.

Where a long feeder is genuinely required for lightning protection or routing, spend the money on the cable instead: 1/2" feeder loses about 0.02 dB/m at 470 MHz, so 20 m costs only 0.4 dB. It needs adapters and demands better workmanship, but it is money well spent.

5. Antenna height matters more than antenna gain

Back to that absurd 24 km. Where did it come from?

Height. LoRa in the Sub-GHz bands is substantially quasi-line-of-sight, and the real limiter is often the radio horizon. With standard atmospheric refraction (4/3 Earth radius):

Radio horizon (km) ≈ 4.12 × (√h₁(m) + √h₂(m))

where h₁ is gateway antenna height and h₂ is device antenna height. Taking the device at 1.5 m:

Gateway antenna height	Radio horizon	vs 2 m
2 m (top of a cabinet, within arm's reach)	≈ 10.6 km	baseline
5 m (second floor, external wall)	≈ 12.5 km	+18%
10 m (roof mast)	≈ 14.6 km	+38%
20 m (tower)	≈ 17.9 km	+69%

Compare that with changing antennas. Going from 3 dBi to 8 dBi buys 5 dB, which at n = 3 improves coverage radius by a factor of about 1.47 (+47%). Raising the antenna from 2 m to 10 m extends the horizon by about 38%.Comparable numbers, but there is one essential difference:

Height costs you nothing. Gain costs you vertical coverage nearby.

And in urban environments you never reach the horizon anyway; obstruction dominates. That is where height wins outright: ten metres up usually means the antenna has cleared the building edge and moved away from every reflective surface on a metal roof. No amount of gain goes through a building.

So the selection order should be:

Win the height first — find the highest compliant mounting position.
Then pick the right gain, not the highest gain.
Choose cable and connectors last — although this is where the cheapest decibels usually are.

6. Verify uplink and downlink separately

This is a very common trap. During commissioning the uplinks look rock solid and everyone signs off on coverage. A week later ADR is not taking effect, Join Accepts are missing, and downlink commands need three retries.

The reason is that the two directions do not balance. Four points:

First, gateway sensitivity is usually better than device sensitivity. ManThink gateways are specified at -141 dBm (SF12, BW 125 kHz). Common device radios such as the SX1262 sit around -137 dBm — roughly 4 dB worse.

Second, gateway transmit power is usually higher. GD73 delivers up to 27 dBm (-1) or 22 dBm (-2); a typical LoRaWAN device transmits at 14 dBm. Another 8–13 dB in the gateway's favour.

Third, many regions impose a separate limit on gateway downlink EIRP. Under the ERC 70-03 framework commonly applied to EU868, most sub-bands cap EIRP at 25 mW (14 dBm), with 500 mW permitted in 869.4–869.65 MHz subject to duty-cycle conditions. That pulls gateway downlink EIRP down to roughly the device's level, leaving the 4 dB sensitivity advantage as the only compensation — so the downlink breaks first, inevitably. Always confirm current limits against the local spectrum authority's regulations and the equipment's type approval.

Fourth, feeder loss is bidirectional. Those 3 dB on the gateway side hurt both links, and in most self-built deployments only the gateway has a feeder at all.

Conclusion: always run two budgets. The uplink budget decides whether you receive data. The downlink budget decides whether joins, ADR and downlink commands work at all. Many two-way applications — valve control, remote verification, configuration pushes, FUOTA — fail on the downlink, not the uplink.

The simplest field test: once installed, perform a join with a real device at the furthest point. A join is inherently bidirectional — the device sends a Join Request and must receive the Join Accept for the join to succeed. A missing 3 dB in either direction shows up there first.

7. Selecting by scenario: five typical combinations

Applying the above to concrete hardware, using documented specifications:

Gateway	Form factor and key specs	Antenna and installation approach
GD61x / GD62 (IP67)	ESP32-S3 + SX1301/SX1302; GD62 is IP67, -25 to 60 °C, 164 × 124 × 50 mm, wall or pole mount, gwTool6 configuration, web OTA with A/B dual firmware partitions	Compact and pole-mountable; connect the antenna with a short jumper. Suited to dense, low-cost single-point coverage
GDI51	Ubuntu gateway with ThinkLink built in (LS1012A); 8 frequency points / 16 demodulators / 65 logical channels; sensitivity -141 dBm; PoE or Type-C	Indoor coverage for smart buildings. Prefer a 2–3 dBi antenna designed for floor-to-floor coverage rather than high gain
GD73	SX1302; type A 8 frequency points / type D 16; `-1` up to 27 dBm, `-2` up to 22 dBm; sensitivity -141 dBm	Projects requiring at least 25 dBm must specify the `-1` version. Suited to campus-scale distance, with a proper mast and low-loss feeder
GDO51	Outdoor IP67; up to 16 frequency points / 32 demodulators / 130 logical channels; sensitivity -141 dBm; PoE / 4G / Wi-Fi / Ethernet / GPS; external SIM slot and debug port; published reference price USD 345 (about ¥2,315, subject to current quotation)	Outdoor and demanding sites. Full outdoor waterproofing is mandatory; connect LTE, GPS and Wi-Fi antennas to their matching labelled ports

One variable is still routinely forgotten: the gateway and the end devices must be in the same regional band. Worth restating because export projects get this wrong more than anything else — CN470 is 470–510 MHz and EU433 is 433–434 MHz. One character differs on the purchase order; the antennas are entirely different.

And a note on product positioning. The GD6 series is an entry-level, edge-side form factor suited to single-point coverage and functional validation. Building-scale and industrial deployments generally need devices with more channels, more demodulators and higher reliability designs — GDI51, GD73 or GDO51. Do not expect an edge-class device to carry a building-scale network's capacity just because you changed the antenna.

8. Ten installation steps, straight from the manuals

Merging the installation requirements from the GD61x, GD62 (IP67) and GD72 manuals gives ten steps. The first three are done with the power disconnected:

Step 1. Confirm the device is powered off and that the LoRa antenna matches the gateway band.
Step 2. Connect the LoRa antenna to the LoRa / RF port and tighten it, letting the connector seat naturally — do not force-twist the connector body.
Step 3. If external Wi-Fi or 4G antennas are supplied, fit them to the matching labelled ports — LTE, GPS/BDS and Wi-Fi each have their own.
Step 4. For cellular backhaul, insert the SIM card, then fit the waterproof cover.
Step 5. For wall mounting, mark out to the bracket hole pattern and use fixings appropriate to the wall material. For pole mounting, check the pole diameter first — the GD72 manual gives a range of 30–52 mm — fit the clamp and tighten evenly.
Step 6. Keep the correct orientation per the supplied installation drawing; the GD72 manual explicitly requires "keep the gateway facing upwards".
Step 7. Leave room for the antenna, connectors and cable bending radius. Never let the cable's weight pull directly on a connector.
Step 8. Route the Ethernet cable through the supplied waterproof gland in assembly order (the seal must match the cable outside diameter), seat the RJ45, then tighten.
Step 9. Complete the waterproofing check, then apply power.
Step 10. Watch the status: the GD61x normal operating indication is an LED slow flash, 1 s on / 1 s off.

Four points on waterproofing

The GD72 manual provides a checkable list. Verify against it:

Every outdoor antenna connector is sealed according to site practice — insulating tape, self-amalgamating tape or dedicated waterproofing material suitable for outdoor use, applied so that it fully covers the joint and forms a continuous seal.
Priority areas: cable entries, antenna ports, SIM card cover, power and network ports.
Drip loop: always leave one, so rain cannot track along the cable into a connector.
Unused ports stay sealed with their original plugs, fitted and tightened.

Two more points on outdoor power: PoE adapters and any supply not rated for outdoor use must sit in a dry location or a suitable enclosure, and the GD72 manual adds that the adapter should be mounted vertically with its ports facing down.

And one point that is easy to forget because it lives on a different timescale:

Inspect sealing material periodically and replace it promptly if aged, cracked or loose.

Where to mount it — and where not to

Drawing on the GD62 (IP67) "Before Use" section and the propagation analysis above:

Avoid: standing water, heat sources, inside metal roofs or cable trays, electrical risers containing high-power equipment, anywhere permanently shadowed by heavy machinery.

Prefer: high points, open aspects, and positions a maintenance technician can reach safely.

Mind the stated environmental limit too: the actual ambient temperature at the mounting position must stay within -25 °C to 60 °C.

9. Six things you must not do

These are the prohibitions written into the documentation. Ignore them and no warranty applies:

Prohibition	Official wording
Transmitting with no antenna	"Connect the LoRa antenna before powering on. Do not start LoRa transmission with no antenna connected."
Mismatched band and accessories	"The RF region must be consistent with the hardware, antenna and end-device configuration." / "Confirm the antenna frequency band matches the gateway's regional version."
Choosing a supply by port name	"Before connecting PoE, check the supply standard, voltage and wiring requirements. Do not select a power source based on the port name alone."
Multiple supplies at once	"Do not connect multiple power sources simultaneously unless expressly permitted in the delivery documentation."
Overvoltage on Type-C / wrong terminals	"Do not apply more than 5 V to the Type-C port. Do not connect a supply to the A+ / B- terminals."
Opening the enclosure or modifying seals	"Do not open the enclosure or modify the sealing structure without authorisation."

Two protection limits from the GD72 manual:

IP67 does not mean submersible: the IP67 rating applies with the enclosure intact and seals and connectors correctly assembled. The unit is not intended for prolonged immersion, and interfaces must not be washed with a high-pressure jet.

These six prohibitions and two limits are the complete set of installation-related restrictions stated in the manuals.

And one operational sequence, from the GD61x manual:

Do not disconnect power during a firmware upgrade, configuration write or factory reset.

10. Commissioning: how to read RSSI and SNR

Finishing the installation is not the end of acceptance testing; it is the start. Two values need recording: RSSI (received signal strength) and SNR (signal-to-noise ratio). They mean quite different things, and reading them together without understanding both leads to wrong conclusions.

SNR decides whether demodulation is possible at all. LoRa is a spread-spectrum modulation, and demodulation depends on the signal exceeding the demodulation threshold for that spreading factor. Typical values from Semtech transceiver datasheets:

Spreading factor	Typical SNR demodulation threshold
SF7	≈ −7.5 dB
SF8	≈ −10 dB
SF9	≈ −12.5 dB
SF10	≈ −15 dB
SF11	≈ −17.5 dB
SF12	≈ −20 dB

The key point: a negative SNR is normal. Demodulating below the noise floor is the whole point of spread spectrum. An SNR of -12 dB is perfectly healthy at SF10.

RSSI tells you how much margin is left. Its absolute value means little on its own — a gateway with -141 dBm sensitivity receiving -115 dBm still has 26 dB of margin, while the same signal at a device with -137 dBm sensitivity leaves only 22 dB. Always read RSSI against the receiver's sensitivity.

Practical acceptance bands:

SNR and RSSI	Reading	Action
SNR ≥ −5 dB, RSSI ≥ −100 dBm	Plenty of margin	Let ADR reduce the data rate and save device power and channel occupancy
SNR −10 to −5 dB, RSSI −110 to −100 dBm	Healthy	Normal operation
SNR close to the SF threshold (margin < 5 dB)	Marginal	Record and re-measure; weather and clutter changes will drop it
SNR below threshold, or RSSI < −125 dBm	Unusable	Check antenna, placement and feeder. Do not paper over it by raising the SF further

Record three things per point: RSSI, SNR, and the SF in use at the time. The same RSSI means completely different margins at SF7 and SF12, and future capacity planning is impossible without the third number.

Also plan for at least two measurement rounds: a baseline at installation, and a re-measurement one to two months later. Antennas and connectors degrade gradually, and a poorly sealed connector commonly shows a 5–10 dB RSSI drop within two months.

11. One page for the field team

A checklist to hand out at project kick-off.

Selection

Confirm the RF region for the gateway suffix; the antenna's frequency range must cover the corresponding band (CN470: 470–510 MHz).
Normalise dBi and dBd before comparing gain. Prefer 2–3 dBi for indoor and dense short-range deployments; consider 5–8 dBi for open line-of-sight.
Confirm VSWR ≤ 2.0 across the operating band (prefer ≤ 1.5). Ask suppliers for a measured sweep across the band, not a single-spot figure.
Decide between the -1 (27 dBm) and -2 (22 dBm) versions, and check local EIRP limits for the band.
Look feeder losses up against the actual band. Beyond three metres, use LMR-400 or better, and keep the connector count down.

Installation

Work de-energised. Antenna on before power.
Match LTE / GPS / Wi-Fi antennas to their labelled ports; never swap them.
Win the height: clear the building-obstruction zone at minimum, ten metres or more where possible.
Waterproof completely: self-amalgamating tape, continuous seal, drip loop, original plugs on unused ports.
Keep the PoE adapter dry, mounted vertically with ports facing down, and not sharing duty with another supply.

Acceptance

Perform a real join at the furthest point to confirm the downlink works.
Record RSSI / SNR / SF for every point as the baseline.
Re-measure after one to two months and compare.

Conclusion

LoRaWAN link budgets usually look like this: twenty or thirty dB of theoretical headroom, and an actual outage caused by an unloved antenna sitting on top of a rack.

The real cause is rarely that the power budget does not add up. It is almost always one of three small things: the antenna is not resonant in the band you are using, the feeder silently ate 3 dB, or the antenna was never taken somewhere it can see the target.

None of the three is expensive, and none appears on the gateway's price list. They show up in the budget under a different heading: the second visit. And the third.

Which is why selection and installation belong in the design phase, not at the tail end of construction.

Official manuals

Connecting ThinkLink to Home Assistant and Node-RED: One MQTT Forwarder Does the Whole Job

manthink — Tue, 27 Oct 2026 09:47:49 +0000

A LoRaWAN project reaches a familiar point: the data is already flowing into ThinkLink, but the interface the customer actually wants to look at is somewhere else — a Home Assistant dashboard, or a flow they have wired up in Node-RED.

That is a reasonable request. Home Assistant dashboards and automation rules are genuinely good, and Node-RED is genuinely handy for stitching systems together. But one fact has to be settled first: neither platform speaks LoRaWAN.

Home Assistant supports MQTT, Zigbee, Z-Wave and HTTP. LoRaWAN is not on that list. It cannot talk to a gateway and it does not parse LoRaWAN frames. Node-RED is in the same position — it is a flow engine, and what it consumes depends entirely on what input node you give it.

So something has to sit in the middle and turn radio frames into structured data. That is what ThinkLink does: the gateway receives the frame, the network server decrypts it, the thing model decoder turns bytes into named fields, and only then does the data become "temperature 24.6" — something an application can actually use.

Which leaves exactly one question: how do you hand that parsed data to Home Assistant or Node-RED?

1. Start with a version change: the built-in HA integration is gone

This belongs at the top, because it determines the whole approach.

Older manuals describe configuring Home Assistant fields in the thing model, or entering an HA address under server configuration. The official 2.00.066 notes are explicit: that release removed the built-in ThingsBoard / Home Assistant integrations and their related fields, and the older HA / ThingsBoard instructions "apply only to older versions and must not be used as operating steps for 2.00.066." The same passage adds that BACnet / Modbus are retained.

From 2.00.066 onwards, there is no "type in an HA address and let the platform push entities" path. What replaced it is a general capability: the MQTT forwarder (Broker + Forwarder).

This is not a regression. A built-in integration hard-codes a single integration shape: the platform pushes in its own format and the other side has to adapt. With a forwarder, topic rewriting, payload restructuring and filtering all live in one JavaScript function, and the mechanism is identical no matter what you are connecting to. Home Assistant, Node-RED, ThingsBoard, a custom service: from ThinkLink's side the only difference is the contents of that script.

One more distinction worth making. Product comparison material mentions that ThinkLink edge deployments (TKG, gateway-embedded) come with Home Assistant OS and ThingsBoard CE as preloaded components. That is a separate HA instance running on the same hardware — it is not "ThinkLink pushing data into Home Assistant." This article is about the latter: getting data out of ThinkLink and into an HA or Node-RED instance you already run.

2. Three possible paths — pick the right one before you start

There is a choice to make first. The documentation describes three push mechanisms, and they are not equally current.

Path	Mechanism	Status	Use it?
Device-side "third-party forward" switch + server-side ThirdParty config	legacy direct push	legacy config, deactivated	no
Server configuration → ThirdParty MQTT	one Broker address configured platform-side	documentation conflict, see below	confirm against your version
Advanced → Broker + Forwarder	subscribe to an internal topic, forward to a target broker	the current supported method	yes

One documentation conflict has to be reported honestly. The MQTT forwarder page states plainly: there is no need to enable any "third-party forward" switch on the device, and no need to configure any third-party platform under server configuration — "both of those settings from older versions are deactivated." Meanwhile the server configuration page still documents a ThirdParty section (Protocol / Host / Port / Telemetry Topic / Username / Password) plus an instruction to enable a ThirdParty switch on the device detail page.

The two pages are describing different things, or at least different versions. The practical resolution is simple: go by what your platform version actually exposes. If the interface has "Advanced → Broker / Forwarder", use the forwarder. That is the main path on current versions and it is what the rest of this article covers.

3. The forwarder: two steps, five fields

The data flow looks like this:

ThinkLink internal broker (AS or ThinkLink)
↓ Source Broker / Subscription Topic
Forwarder rule (optional JavaScript transform)
↓ Target Broker
Third-party MQTT broker (Customize)

Step 1: create two broker connections

Go to Advanced → Broker. One forwarder rule needs one source connection and one target connection.

Source broker — two internal types, and the choice determines what shape of data you get:

ThinkLink: telemetry after thing-model decoding. Fields already have names and units.
AS: raw uplink after LoRaWAN decryption, before the thing model.

Pick ThinkLink for almost everything. There is only one good reason to choose AS: you want to do your own parsing downstream, or you need RF-side values like RSSI and SNR for network quality analysis. If the goal is "show a temperature in Home Assistant," choosing AS means redoing work the platform has already done.

Addresses and tenant credentials for the internal brokers are filled in by the platform; you do not need to fetch them from server configuration.

Target broker — add a Customize entry with the other side's details:

Name and enabled state
MQTT URL, e.g. mqtt://192.168.1.50:1883 or mqtts://host:8883
Username and password (when required)
CA certificate, client certificate and other TLS material (when required)

If Home Assistant and Node-RED run on the same host — the common case — the target is the Mosquitto instance on that host, or the Mosquitto broker add-on inside HA.

After saving and enabling, check the broker list state first: RUNNING is healthy; ERROR means read ErrMsg and work through URL, port, credentials, certificates, and network reachability.

Step 2: create the forwarder rule

Go to Advanced → Forwarder → Add:

Field	Meaning
Name	Rule name
Enabled	The rule only subscribes and forwards when this is on
Source Broker	Broker to subscribe to
Target Broker	Broker to publish to
Subscription Topic	Topic on the source broker; supports MQTT `+` and `#` wildcards
Custom Script	Optional; rewrites topic, message body or retain flag
Remark / commit note	Optional; documents the rule and version changes

One hard constraint: Source Broker and Target Broker may not both be internal types (AS / ThinkLink), to avoid a pointless internal loop. The normal third-party combination is:

Source Broker = AS or ThinkLink
Target Broker = Customize

How to fill in Subscription Topic

This is the field most often got wrong, because there is no default and the placeholder must be replaced.

Source Broker	Data	Subscription Topic
`ThinkLink`	telemetry after thing-model decoding	`/v32/{tenant}/tkl/up/telemetry/#`
`AS`	raw uplink after LoRaWAN decryption	`/v32/{tenant}/as/up/data/#`
`AS`	complete uplink after multi-gateway collection	`/v32/{tenant}/as/up/dataAll/#`

{tenant} must be replaced with your actual organisation account, visible in your profile — do not leave the placeholder in place. # covers every device in the organisation; to forward a single device, replace # with that device's DevEUI.

Concretely: organisation account mtfac, forwarding decoded telemetry for all devices, gives /v32/mtfac/tkl/up/telemetry/#.

4. The transform script: translating ThinkLink into HA's vocabulary

With no script configured, the forwarder passes topic and payload straight through. That is a good starting point: let messages flow unchanged, capture one real message in Home Assistant or Node-RED, look at the actual field structure, and only then decide whether you need a script. Scripts written from imagination rarely work the first time.

When you do need to reshape the payload, there is exactly one entry function:

function forwardScript({ topic, msg, org_params }) {
if (!msg?.telemetry_data) return null

return {
topic: ${org_params.target_topic_prefix}/${msg.device_id},
option: {
retain: false
},
msg: {
temperature: msg.telemetry_data.T,
humidity: msg.telemetry_data.H
}
}
}

Three inputs: topic is the original topic the message arrived on, msg is the parsed message body, and org_params is read-only organisation parameters.

The returned object supports three fields: topic (the topic to publish on the target broker), msg (the body to publish), and option (MQTT publish options such as { retain: true }). Returning null, or returning nothing, discards the message — which is the intended way to filter, for example forwarding only certain devices or only when a value crosses a threshold.

The official example uses msg.device_id and msg.telemetry_data; the keys under telemetry_data (shown as T and H) are whatever your thing model defines. Do not guess field names — capture a real message and confirm. Article 21 covered thing model decoders: the keys defined there are the keys available here.

org_params deserves a note of its own. It is an organisation-level set of environment variables, maintained as key/value pairs under System Management → Server Configuration → Org Params, shared across the whole tenant and injected automatically when the platform runs a script. The point is to move addresses, prefixes and business identifiers out of scripts — change environments or topic prefixes in one place instead of editing every script. Values take effect immediately, with no service restart, and only organisation administrators can see them.

5. Home Assistant: two ways in

Note: the Home Assistant configuration below is general Home Assistant knowledge, not ThinkLink official documentation. HA moves quickly — check field names against the version you run.

Once data reaches the broker HA uses, HA has to turn it into entities. Two routes.

First: hand-written MQTT sensors. Declare sensors in configuration.yaml, point state_topic at whatever topic the forwarder publishes to, and pull the value out of the JSON with value_template. This is the most robust option and you control every field; the cost is a block of config per measurement per device. Well suited to a small, fixed set of devices.

Second: emit MQTT discovery messages yourself. Home Assistant's MQTT integration supports discovery: publish a message carrying device metadata to the agreed discovery topic (prefix homeassistant/ by default) and HA creates the entity automatically. ThinkLink does not emit that format natively, but you can build it inside the forwarder script — both topic and msg in the return value are yours to define, so the first uplink can trigger a discovery message.

That route wins when devices are numerous or change often: adding one requires no HA config edits. The cost is script complexity and one round of debugging.

One structural point worth planning for: ThinkLink sends one message per device containing multiple fields, while an HA entity holds one value. Either split it on the HA side with value_template, or split it in the forwarder script and publish one topic per field. Deciding which layer does the splitting up front saves a lot of rework.

And a practical warning: an entity showing "unknown" or "unavailable" in the HA dashboard is often not an HA problem — the data never reached the broker. Subscribe from the command line and confirm the message actually arrives before touching HA configuration.

6. Node-RED: three nodes and you are running

Node-RED is more straightforward than HA, because it imposes no entity model — it processes whatever arrives.

The minimal flow is three nodes: mqtt in (subscribe to the topic on the target broker) → json (parse the string into an object) → debug or a dashboard node.

The topic in mqtt in is whatever the forwarder published, i.e. the topic returned by forwardScript. If you left it pass-through with no script, that is the original /v32/mtfac/tkl/up/telemetry/{eui}.

Where Node-RED beats HA is the middle of the flow: you can drop in function nodes for arbitrary logic — unit conversion, thresholds, cross-device correlation, database writes, third-party API calls. For something like "when temperature and humidity exceed limits, check another sensor in the same zone and only alert if both are over," Node-RED reads more clearly than a platform-side trigger script and is more flexible than an HA automation.

Reverse control is equally a single mqtt out node — but read the next section first.

7. Writes: from HA / Node-RED back to the device

This is where misjudgement creeps in, and it is the same lesson as the BACnet write path in article 24.

From pressing a button in HA to the device actually acting, at least three things must happen:

The command is accepted by the platform — immediate.
The RPC reaches the device — on a Class A LoRaWAN device the downlink can only go out in the receive window after an uplink (RX1 ~1 s, RX2 ~2 s). With a ten-minute reporting interval, that command can sit for ten minutes before it lands.
The device reports back — the result of the execution only shows up on the next uplink.

So clicking a button in HA and seeing nothing change does not mean the command failed. Acceptance criteria should read "read back and confirm within N reporting cycles after sending," not "click and look immediately."

One recommendation for integrators: if the project needs control latency measured in seconds, a Class A device is the wrong choice and Class C should be considered. That decision belongs at device selection time — it cannot be fixed during integration.

8. Online status: one switch you have to turn on yourself

Both HA and Node-RED need to know whether a sensor is still alive.

From 2.00.084, a forwarder with a ThinkLink source can subscribe to the device status topic:

/v32/{tenant}/tkl/device/status/{eui}

or, within an authorised organisation, /v32/{tenant}/tkl/device/status/+.

Two traps to know in advance:

First, status messages require notify_offline="TRUE" on the device, and that switch defaults to off. Leave it off and there are no status messages at all — no amount of forwarder configuration will produce them. Note that the forwarder itself needs no device-side "third-party forward" switch; whether status messages exist depends solely on notify_offline.

Second, this message has no telemetry_data. The example script above opens with if (!msg?.telemetry_data) return null, which discards status messages outright. To forward status, either leave the message pass-through or handle the status format explicitly in the script.

Also worth pinning down: "online" has three definitions on the platform and they are not interchangeable (article 22 covered this) — the activity time in the device list, server_attrs.online, and the boolean in MQTT notifications. Whichever one your integration uses should be written into the delivery document, so both sides do not hold different ideas of what "online" means.

9. After 2.00.070: do not just watch for RUNNING

Connection and subscription behaviour changed in 2.00.070, and it directly affects troubleshooting.

Registration is not subscription. When a rule is enabled, the subscription requirement is registered even if the source broker is offline, and the subscription is attempted once the connection recovers. But subscription is only confirmed on SUBACK. Failed subscriptions retry every 3 seconds while connected.

No buffering when the target is down. At startup, a rule waits for its own enabled target broker within the original connection timeout, then registers the source subscription anyway; when the target is unavailable it falls back to skipping the forward. There is no new message buffering and no offline redelivery guarantee. The forwarder is not a reliable queue — messages produced during an outage are not replayed afterwards.

No exactly-once. MQTT redelivery or duplicate sends at the source can produce duplicate messages; if the business needs deduplication, carry a message identifier.

In short: do not conclude that forwarding works from "rule enabled" or "broker connected" — verify the actual message flow.

Two more behaviours: forwarder brokers for the same organisation load in parallel, so one slow connection does not make the others queue. When several scripts share a topic, removing one does not affect the others; unsubscribe only happens once the last callback is removed.

10. Troubleshooting: work this order

The official five steps hold up well in practice:

Confirm both source and target brokers are enabled and the target shows RUNNING.
Check ErrMsg, host, port, credentials and TLS certificates.
Confirm the forwarder itself is enabled (not merely saved).
Confirm Subscription Topic matches the real message topic — especially whether {tenant} was substituted and whether a path level is missing or extra.
Disable the custom script temporarily and confirm the raw message passes through; then debug the script's return value.

Step 5 is the one most often skipped and the one that most often finds the problem. The classic beginner error is a script returning null (because msg.telemetry_data was absent) without realising it — the symptom looks like "data isn't being forwarded," when in fact the script is throwing it away.

Two operational extras:

Every save of a forwarder script creates a version snapshot, viewable and restorable in the editor. Restoring creates a new version record and does not delete history — a broken script is recoverable.
The system platform maintains public forwarders: public rules are visible but read-only in the tenant; selecting a specific organisation lets a rule reference that organisation's brokers and org_params. Useful when multiple organisations share one forwarding pattern.

11. Acceptance checklist

#	Item	Pass criterion
1	Path	Uses "Advanced → Broker + Forwarder"; does not rely on the deactivated legacy third-party switch
2	Source broker	`ThinkLink` (decoded) or `AS` (raw) chosen deliberately, not by accident
3	Target broker	Type `Customize`; state `RUNNING`; `ErrMsg` empty
4	Subscription topic	`{tenant}` replaced with the real organisation account; path levels match the documented format
5	Rule enabled	Forwarder "enabled" is on (not just saved); SUBACK received
6	Real message flow	Verified by subscribing on the target broker, not inferred from status
7	Script behaviour	Pass-through validated first; with the script on, no unintended `null` discards
8	Field naming	Keys under `telemetry_data` confirmed against a real message, not guessed
9	HA / Node-RED side	Entities or flow read values that match what the platform shows
10	Online status	`notify_offline="TRUE"` set; status topic subscribed and not discarded by the script
11	Write control	Read back and confirm within N reporting cycles; "send succeeded" is not acceptance
12	Disconnection behaviour	Confirmed that messages during an outage are not redelivered; dedup or compensation designed
13	Versioning	Forwarder script version, platform version and target broker config recorded

12. Closing

From 2.00.066, ThinkLink replaced "integrate with one specific platform" with "integrate with any MQTT endpoint." For Home Assistant and Node-RED that is not bad news — a built-in integration can only offer one fixed payload shape, whereas the forwarder offers somewhere to write your own translation.

The cost is that the script is yours to write and debug. But the boundaries are clear: topics follow a documented format, the script has one entry function, the return value has three fields, and there is a documented five-step troubleshooting order. What actually goes wrong is detail — {tenant} left as a placeholder, a script silently returning null, status messages carrying no telemetry_data, messages during a target outage never being replayed.

Put those details into an acceptance checklist. It is faster than trial and error.

Related reading

Article 21: Writing Payload Decoders in ThinkLink — From 15 Bytes to Readable Data
Article 22: ThinkLink Trigger Models and Alarm Rules — Alerts That Arrive on Time and Get Read
Article 24: Connecting ThinkLink to BACnet/IP and Modbus TCP — From Field Mapping to YABE Verification

Based on ThinkLink official documentation; paths and parameters follow your actual platform version. Official manuals:
https://www.think-link.net/docs/en/Advanced/MQTTForwarder.html
https://www.think-link.net/docs/en/QuickStart/SystemManagement/ServerConfiguration.html
https://www.think-link.net/docs/en/Protocol/ThinkLinkProtocol.html

Connecting ThinkLink to BACnet/IP and Modbus TCP: From Field Mapping to YABE Verification

manthink — Mon, 26 Oct 2026 09:35:08 +0000

Currency note. Figures in this article are quoted in CNY. Where a source price was published in another currency, the CNY equivalent is converted at the fixed October 2026 reference rate of 1 USD ≈ 6.71 CNY, with the original currency shown alongside. Publicly listed prices come from different sources with inconsistent scopes; they indicate order of magnitude and are not a sourcing recommendation.

A LoRaWAN project is finished. The sensors are mounted, the gateway is online, and the platform shows clean curves. Then the customer asks a single question: can this data get into the building management system we already have?

What follows that question is work nobody particularly wants. Building management speaks BACnet. The plant floor speaks Modbus. LoRaWAN speaks neither. So you either buy another protocol gateway, or you pay an integrator to write a bridge service that translates MQTT messages into point values. That work produces no new data — it only makes data you already have readable by a system that cannot read it. And yet it has a price, a schedule, and a change-management process attached to it that runs for the life of the project.

ThinkLink ships a built-in BACnet/IP service and a built-in Modbus TCP Server in its TKE (edge server) and TKG (in-gateway) forms, and that is exactly what they are for. This article walks the integration in the order it actually happens: when you can use them, how fields become points, what has to be checked before you hand over a point list, and why "the point table saved successfully" is not the same thing as "the BMS is reading values."

1. Scope First: BACnet and Modbus Are TKE / TKG Only

This is the first thing to settle, because it is a hard boundary rather than a configuration issue.

The official documentation states the same thing in three places: the BACnet service is supported only on independently deployed TKE devices and gateways running TKL (TKG); the cloud version does not provide it. The Modbus TCP Server carries an identical restriction.

Deployment form	BACnet/IP	Modbus TCP Server
Cloud (public SaaS)	Not supported	Not supported
TKE (local server / industrial PC)	Supported	Supported
TKG (embedded in gateway, e.g. GDO51 / GDI51)	Supported	Supported

This is not a feature that was withheld. It follows from the protocol. BACnet/IP runs on UDP 47808 (0xBAC0) by default, and device discovery depends on local broadcast: a workstation sends a Who-Is broadcast and every device that hears it answers with an I-Am. That works inside one broadcast domain. IP routers do not forward broadcasts, so crossing subnets requires a BBMD (BACnet Broadcast Management Device). A multi-tenant public cloud has neither a customer's on-premise broadcast domain nor a fixed UDP port into their internal network. This is architecture, not backlog.

So align sales and pre-sales on this before the proposal goes out: if the customer is on Cloud, the data leaves via the MQTT forwarder or the REST API, and the integrator lands it into points on their side. Promising "BACnet points straight from the cloud into your BMS" is a commitment that fails during implementation.

There is a second operational constraint that is easy to miss: a single backend process runs the BACnet service for one organisation only. Starting BACnet in another organisation stops the previous organisation's instance; you cannot run multiple organisations in parallel on different ports within one process. The Modbus TCP Server behaves the same way — one instance serves one organisation, and switching service organisation replaces the running instance. A multi-tenant edge deployment (one TKE serving several subsidiaries, say) has to be designed for explicitly. Parallel operation is not the default.

2. What This Segment Actually Costs: The Industry Prices by the Point

Building automation and industrial integration share a unit of account: the point. One temperature, one valve state, one meter reading — each is a point. Once you internalise that, it becomes clear what a built-in protocol service removes.

Two sets of publicly listed figures (2026):

China — BA system software pricing, software and commissioning included

Scope	Listed price	Per point
200 control points	~CNY 18,000	~CNY 90/point
500 control points	~CNY 26,000	~CNY 52/point
1,000 control points	~CNY 38,000	~CNY 38/point
2,000 control points	~CNY 46,000	~CNY 23/point

The broader industry range for medium projects (roughly 2,000–5,000 points) is about CNY 80–200 per point, covering controllers, sensors, software licences and commissioning; high-spec environments such as hospital clean rooms and data centres push past CNY 300 per point. The two sets differ in scope — the first is mostly software platform, the second includes hardware and installation — so treat both as order-of-magnitude only.

Overseas retrofit pricing (original currency; CNY at 1 USD ≈ 6.71)

Retrofit type	Listed price	Converted
Equipment with native BACnet/Modbus, connected directly	$200–500 / point	~CNY 1,342–3,355 / point
Equipment needing a protocol gateway	$500–1,500 / point	~CNY 3,355–10,065 / point
Equipment over 20 years old, controller replacement	$1,500–4,000 / point	~CNY 10,065–26,840 / point

The middle row is the one that matters: points that need a protocol gateway cost 2.5 to 3 times what directly connected points cost. A 2026 UK BMS cost guide lands in the same place, quoting £300–600 per connected point and naming point count as the primary cost driver.

That is the value of an embedded protocol service. It moves LoRaWAN data out of the "needs a protocol gateway" bucket and into the "connects directly" bucket. What it saves is not sensor money — it is the 2.5× multiplier on every point, plus the recurring cost of re-running the change process every time the point list moves.

3. BACnet vs Modbus: You Are Delivering Objects, or You Are Delivering Addresses

Both protocols expose platform data to a third-party system. What you hand over is completely different, and that is where selection usually goes wrong.

Dimension	BACnet/IP	Modbus TCP Server
Data model	Object model: Analog / Binary Input, Output, Value	Register model: address plus bits or words
Self-describing	Yes — object name, description, units, data type	No — everything is convention, carried in a spreadsheet
Discovery	Broadcast Who-Is / I-Am; the BMS can find devices	None; the client must be pre-configured with addresses
Change notification	COV subscription (`cov_increment` threshold)	None; the client polls
Write path	Write to an Output/Value object → bound RPC fires	Write to a register → bound RPC fires
Counterpart	Building management systems, DDC controllers	SCADA, HMI, PLC
Transport	UDP, default 47808	TCP, default 502

One line separates them: BACnet for building automation, Modbus for the industrial side. You can run both at once — a single TKE can publish BACnet objects to the BMS and Modbus registers to SCADA independently. They have separate service permissions and separate ports.

The test is simple. If the other system can scan the network and list point names by itself, you are in the BACnet world. If the other engineer opens with "send me the point list and tell me what 40001 is," you are in the Modbus world.

4. BACnet in Five Steps, in This Order

Step 1 — the system administrator enables the service permission

From 2.00.077, System Platform → System Configuration carries two independent switches, ModbusTcpServer and BACnet, stored in system_param.service_enable (not as a sub-field of config).

Two details matter:

Only a JSON boolean false disables it. A missing key, null, or an empty object all default to allowed. Do not leave the field blank.
Disabling stops the service, blocks configuration and point-table operations, and prevents both manual start and automatic recovery. Configuration and point tables are retained; re-enabling requires a manual restart — nothing starts on its own.

Step 2 — configure the BACnet fields in the thing model

Before enabling the BACnet service, you must configure BACnet attributes for the fields you want to expose, inside the thing model. The thing model field's unit maps to the BACnet object's units.

This is the most common source of rework: a deliverable thing model has four parts — the parser script, the display fields, the Modbus mapping, and the BACnet fields. A working script that parses data correctly is not the same as having the BACnet fields configured. Article 21 covered the parser script and article 22 covered triggers; this is a fourth, separate block of configuration work.

Step 3 — enable BACnet on the device

Device details → Basic Information, enable BACnet (on the Modbus side the equivalent is setting modbus_tcp to TRUE).

Only devices with this switch on get mapped. When you generate a point table by thing model, it covers only devices already bound to that thing model and already enabled for BACnet — it does not generate objects for every device in the tenant.

Step 4 — generate the point table

Operations → BACnet → Incremental Generate → select the thing model → confirm.

You can also add objects manually. Constraints for the manual form:

Field	Requirement
Eui	Required; select the device to map
data_from	From 2.00.085, free text; defaults to `telemetry_data`
thing_model	Required for telemetry sources only; attribute sources save it as an empty string
field_name	Required; a thing model field for telemetry, an attribute path for attribute sources
object_type	Defaults to `analogOutput`; choose according to the actual read/write purpose
object_id	Required; 0–4194303
object_name	Required; the name the integrator will see
default_value	Defaults to 0; lower bound 0
units	Defaults to `noUnits`; mapped from the thing model field's `unit` when one is selected
cov_increment	Required; defaults to 0, lower bound 0; change-notification threshold
description, RPC	Optional; bind an RPC when you need write control

From 2.00.077 the "Apply point table" button is gone from the UI. Saving, deleting, importing, incrementally generating and renumbering objects automatically synchronise the running service. The reverse is also true: saving a point table does not start a stopped service — starting is a separate action in the service configuration.

Step 5 — configure service parameters and restart

System Management → Server Configuration → BACnet. Fill in the network and device parameters, click Submit, then click Restart.

Parameter	Meaning	Reference value	Editable
IP address	Local IP of the host running TKL; `0.0.0.0` binds all interfaces	`0.0.0.0`	Yes
Port	BACnet listening port	`47808` (UDP, i.e. 0xBAC0)	Yes
Device ID	Unique BACnet device identifier, must be unique in the system	`1`	Yes
Vendor Identifier	Vendor identification number	Per actual vendor	Yes
Device Name	Name shown in the BMS	`TKE`	Yes
Max APDU Length Accepted	Maximum accepted APDU length	`1024`	Yes
Segmentation Supported	Current version does not enable segmentation through this field	As shown in the form	Confirm compatibility with the BMS party

Reference values are for field configuration only — they do not mean the new-entry form is pre-filled. Read the existing configuration and confirm each item with the BMS integrator. Changing listening parameters still requires Submit followed by Restart.

5. Three Point-Table Constraints With Long Reach

1. object_id runs 0–4194303, and renumbering changes what the integrator is using

The list offers a "renumber object id" action. It looks like housekeeping. It changes the object identifiers the integrator is already using — the BMS addresses points by object instance number, so one renumbering pass on your side misaligns every point on theirs. After renumbering you must reissue the delivered point list and tell the integrator to reconfigure.

The permitted range is 0–4194303, which reflects the 22-bit object instance number field in BACnet. BACnet device instance numbers must also be unique across the entire BACnet internetwork; duplicates produce intermittent faults that are genuinely unpleasant to diagnose, because the symptom is "sometimes it does not read," not "it never reads."

2. `data_from` is free text, not an enum

From 2.00.085, BACnet fields carry data_from. Its type is a free string (varchar(32)), not a fixed enum. Three values are suggested:

`data_from`	Meaning and configuration
`telemetry_data`	Default; `thing_model` required, field read from `device.telemetry_data[thing_model]`
`server_attrs`	Reads an attribute path from `device.server_attrs`; no thing model, saved as `""`
`shared_attrs`	Reads an attribute path from `device.shared_attrs`; saved as `""`
Any other string	Reads from the device's own attributes; falls back to `default_value` if the source does not exist

Memorise the fallback rule: unknown source, missing value, null, empty string or whitespace all fall back to default_value; but numeric 0 and boolean false are preserved.

Which leads to the important conclusion: a default value is not evidence of the device's real state. A fallback to 0 may mean "the value is 0" or "the source does not exist," and the BMS displays both identically.

3. The unique key is a four-tuple, not a field name

An object's business key is (eui, data_from, thing_model, field_name). BACnet fields in the thing model use the "source + field name" composite key. Same-named fields from different sources can coexist — so do not deduplicate on field name alone; you will delete the wrong one.

Related: adding an attribute object directly does not require a thing model, but incremental generation by thing model still only covers devices bound to that model with BACnet enabled, and will not generate status objects for all devices automatically. If you want an "online" point, add it manually.

6. Turning "Offline" Into a Point the BMS Can Read

A BMS needs to know whether a sensor is still alive. On the ThinkLink side, you expose online status as an attribute point.

Three steps:

In the device's basic information, set notify_offline = "TRUE" and configure the real heartbeat period (confirm the source of the detection state).
Add a BACnet object manually: pick the real device EUI and a non-conflicting object ID/name, set source to server_attrs, field to _online, type to binaryInput, units to noUnits.
Save the point table, confirm the running service synchronised, then check online, timeout-offline and recovery from the BMS.

Key fields when creating it (EUI, object identifier and other required fields also apply):

"data_from": "server_attrs",
"thing_model": "",
"field_name": "_online",
"object_type": "binaryInput",
"units": "noUnits",
"default_value": 0

One warning belongs in the handover document: a default_value of 0 does not prove the detection result is offline — a missing attribute also returns 0. With offline notification disabled, _online can freeze at its last state.

Online status also has three non-interchangeable meanings on the platform (covered in article 22): the activity time in the device list, server_attrs.online (a number 1/0 maintained by the detector), and the boolean data.online in MQTT notifications. notify_offline is a string switch on the device or template, "TRUE"/"FALSE", disabled by default — when it is not enabled, or missing, you may not treat the device as offline.

7. Modbus TCP: Four Register Types and Ten Encodings

Three configuration steps

The system administrator enables ModbusTcpServer under organisation service permissions.
System Management → Server Configuration → Modbus TCP Server: set the listening port (usually 502), Submit, then Restart.
Device details → Basic Information: set modbus_tcp to TRUE.

Register mapping entries

Operations → Modbus TCP → register list; add mappings for enabled devices:

Field	Meaning
Device EUI	The device whose data is being mapped
Register type	`coils` (1 bit, R/W) / `discrete_inputs` (1 bit, read-only) / `holding_registers` (16 bit, R/W) / `input_registers` (16 bit, read-only)
Register address	Hex; the platform detects conflicts, addresses must be unique within a type
Data source	`telemetry_data` / `shared_attrs` / `server_attrs`
Field path (`name_path`)	The field name; multi-level paths supported, e.g. `temperature`, `sensor.value`
Value type	`string`, `boolean`, `Int16LE`, `Int16BE`, `Int32LE`, `Int32BE`, `FloatLE`, `FloatBE`, `DoubleLE`, `DoubleBE`; there is no generic `number` option
RPC binding	Optional; when the client writes this register, the bound RPC fires

Three form-filling traps

Addresses are hex, register counts are decimal. Do not mix the two.

The register count is computed from the type and cannot be edited. Selecting FloatBE shows a count of 2. When you allocate the following address, account for the full length occupied — a FloatBE consumes two 16-bit registers, so the next point must start two addresses later. Checking only the start address will overlap them.

LE/BE is an encoding choice and must match how the reader interprets bytes. Choose FloatBE on the platform while the SCADA decodes little-endian and you get a completely wrong number, with no error raised.

Read and write behaviour

Reading: when the client reads a register, ThinkLink returns the current value of the mapped field. The value refreshes on each device uplink — no polling configuration is needed.

Writing: the register must have an RPC bound. ThinkLink calls the bound RPC with the written value as a parameter, in the form { _eui, [field_name]: value }, with the call source marked bacnet_server (the same mechanism applies on the Modbus side).

Typical use: SCADA writes a holding_registers value to change the sampling interval; ThinkLink fires a "set sampling interval" RPC down to the device.

8. The Write Path: Three Things to Accept Separately

This is where integration disputes come from. The documentation is deliberately careful in its wording:

A successful BACnet write does not mean the device has executed it; check the device reply or a subsequent uplink.
Write accepted, device execution succeeded, and attribute persistence completed must be verified separately.

The three stages:

Write accepted — the platform received the request and the object value in the point table may already be updated. This completes in seconds.
Device execution succeeded — the RPC reaches the device and the device actually changes the parameter. For a Class A LoRaWAN end device, a downlink can only be sent in the receive windows after an uplink (RX1 at roughly 1 s, RX2 at roughly 2 s). A device that reports every ten minutes may take ten minutes to receive the command.
Attribute persistence completed — the device reports the new value back, it is written to attributes, and the BMS sees the real result on its next read.

A failure at any stage presents as "the BMS shows the write succeeded but the device did not change." If the RPC fails or the device reports its original value, a later attribute notification can push the true cached value back — but that push arrives on the next attribute update, not immediately.

So on the acceptance sheet, write control should be specified as "read back and confirm within N reporting cycles," not "write operation returned success."

9. Network and Ports: 47808 Does Not Work Just Because You Configured It

The networking requirements for BACnet/IP are more specific than most people expect.

UDP 47808, both directions. Firewall rules must permit UDP 47808 inbound and outbound. An outbound-only rule means the workstation can send Who-Is and will never see an I-Am come back.

Broadcast only works inside one broadcast domain. The workstation sends a Who-Is broadcast and only devices on the same Layer-2 segment answer. Put an IP router in between and the router does not forward broadcasts, so discovery fails silently — the workstation reports "nothing found," never "network unreachable." The standard fix for crossing subnets is a BBMD: one per subnet holding devices, each carrying a Broadcast Distribution Table naming its peers. A broadcast is unicast to those peers and re-broadcast locally by each.

A few hard rules when configuring BBMDs: the distribution table must match on every BBMD — a subnet listed in one table and omitted from the others is reachable in one direction only; the BBMD's own address must be static, because foreign-device registrations and peer table entries point at it by address; and two BBMDs on the same subnet is a configuration error, not redundancy, producing duplicate traffic and duplicate I-Am answers.

NAT breaks BACnet/IP. BACnet/IP carries the originating address inside the message payload — in the Forwarded-NPDU a BBMD sends, and in a foreign device registration. NAT rewrites the IP header and leaves the payload alone, so requests get out and replies never arrive. The workable path is a routed or VPN connection, not address translation.

Site-to-site VPNs and wireless bridges frequently drop broadcast. Unicast working is not evidence that broadcast works; supervision across such a link normally needs foreign-device registration rather than plain discovery.

One deployment-level note. The TKE Docker deployment guide lists host inbound ports (80/8080, 443, 18083, 18084, 1883, 8883, 8083, 8084, 1700 UDP, 9000, 9001) and does not include 47808 or 502. The installer does not create mappings or allow rules for these two services; the deployment team has to confirm container port mapping, host firewall and security group rules themselves. Miss this and the symptom is "the platform says the service is running, but the BMS finds nothing."

One last item is a security requirement rather than an option: BACnet was designed for isolated control networks, and much of the installed base has little or no authentication. Once the control network is reachable from the business network, that assumption no longer holds. Both UDP 47808 and TCP 502 should be reachable only from the building automation or SCADA segment — never from the public internet.

10. Verifying With YABE, and Delivering the Point List

A five-minute loop with YABE

YABE (Yet Another BACnet Explorer) is the common tool for browsing and debugging BACnet devices. Once configured, connect YABE to ThinkLink to discover the published BACnet devices and their object properties, and confirm the data is being published correctly.

Work through the checks in this order; each one isolates a different class of problem:

Check	Pass criterion	First suspect if it fails
Device discovery	YABE sees the Device ID and Device Name	UDP 47808 blocked / no BBMD across subnets / service not restarted
Object list	Count and object_ids match the point table	BACnet not enabled on the device / thing model BACnet fields not configured
Read value	presentValue matches platform telemetry	Wrong field name or source / value fell back to default
Units	units shows the expected unit (e.g. degreesCelsius)	`unit` not filled in the thing model field
COV	Notification arrives when change exceeds the threshold	`cov_increment` set to 0
Write control	Device read-back changes after writing an Output/Value	No RPC bound / Class A downlink window not reached

Modbus has no general-purpose browser equivalent; you typically use a Modbus master utility (Modbus Poll and similar) to read addresses one by one against the point list. Focus on two things: the address convention (hex vs decimal) and byte order (LE vs BE).

Delivering the point list

Both BACnet and Modbus point lists export to Excel and import back for bulk configuration. The export contains object type, address, name, description, data type, units and read/write permissions — exactly what the integrator needs to configure their client.

One caveat on import: entries with an existing ID are overwritten. This is the same class of risk as the Excel migration traps covered in article 23 — export a backup before importing, because the overwrite cannot be rolled back.

Two delivery recommendations:

Version the point list. Record the point list version alongside the thing model version and the platform version. If BACnet object identifiers shift, every point on the BMS side is misaligned, and retrospective investigation costs far more than keeping a record.
Deliver first, then commission together. Hand the point list to the integrator, let them configure their client, then commission jointly. That is much faster than adjusting the point list during commissioning. Point-table saves do synchronise the running service automatically, but every change forces the other side to reconfigure.

11. Acceptance Checklist

#	Item	Pass criterion
1	Deployment form	Confirmed TKE or TKG; Cloud exposes neither BACnet nor Modbus
2	Service permission	Both BACnet and ModbusTcpServer explicitly `true` in system configuration
3	Thing model	All four blocks done: parser script, display fields, Modbus mapping, BACnet fields
4	Device switch	BACnet / `modbus_tcp` enabled on target devices
5	Service parameters	Device ID unique network-wide; Port agreed with the BMS party; submitted and restarted
6	Port reachability	UDP 47808 open both directions (BBMD deployed if crossing subnets); TCP 502 open to the control segment only
7	Point list completeness	Object/address, name, data type, units, R/W permission all present; write points have RPCs bound
8	Read correctness	YABE / Modbus master reads match platform telemetry, units correct
9	Status point	`_online` point exists and online, timeout-offline and recovery have all been tested
10	COV	`cov_increment` set to a real precision value, not 0
11	Write control	Confirmed by read-back over reporting cycles, not by write success alone
12	Runtime monitoring	No point-table sync errors or retries; service restarts automatically after abnormal exit, and does not resurrect after a manual stop
13	Deliverables	Point list Excel exported and versioned; backup taken before any import

12. Closing

Getting LoRaWAN data into a BMS or SCADA is not fundamentally hard — the protocols are public and a bridge can always be written. The real cost is that every point has to be configured by someone, checked by someone, and changed again by someone throughout the project's life. The industry prices by the point; points that need a protocol gateway cost 2.5 to 3 times what direct points cost. That number prices integration labour, not software features.

ThinkLink's built-in BACnet/IP and Modbus TCP on TKE and TKG remove that segment. What they do not remove is engineering discipline: BACnet is available only in the self-hosted forms, one process serves one organisation, renumbering a point list breaks the integrator's configuration, a successful write is not a successful execution, and UDP 47808 needs two-way rules plus a BBMD once you cross a subnet.

All of these are documented. They are just spread across different pages. Collecting them into an acceptance checklist is the cheapest way to get the integration right the first time.

Related reading

Article 21: ThinkLink Thing Model Decoder Scripts in Practice — Turning 15 Bytes Into a Readable Table
Article 22: ThinkLink Trigger Models and Alarm Rules in Practice — On Time, Not Spammy, To the Right Person
Article 23: ThinkLink Edge On-Premises Deployment in Practice — What "Data Never Leaves the Plant" Actually Requires

Based on official ThinkLink documentation (versions 2.00.077–2.00.085). Configuration paths and parameters follow your deployed version. Official manuals:
https://www.think-link.net/docs/en/Maintenance/BACnet.html
https://www.think-link.net/docs/en/Maintenance/ModbusTCP.html
https://www.think-link.net/docs/en/QuickStart/SystemManagement/ServerConfiguration.html

ThinkLink Edge On-Premises Deployment in Practice: What "Data Never Leaves the Plant" Actually Requires

manthink — Fri, 23 Oct 2026 09:06:53 +0000

Currency note. Figures were collected from Chinese public channels in October 2026. Where a price was quoted in CNY, the USD figure is converted at the fixed October 2026 reference rate of 1 USD ≈ 6.71 CNY. Hardware prices are indicative of order of magnitude and are not a sourcing recommendation.

"Data must not leave the plant." It shows up in industrial IoT tenders as a single line, usually in the third clause of the technical specification, with no further explanation. The integrator wins the bid, buys an industrial PC, installs the on-premises version of the IoT platform, passes acceptance, and the job looks done.

The problem is that the sentence describes where data sits. It says nothing about how data moves inside the plant. Once you place a seven-container platform on the shop-floor network, questions do not disappear because the data stays local — is MQTT in cleartext, who can reach the object-storage console, how large will the history table be in twelve months. Centralising data tends to enlarge the internal attack surface, not shrink it.

This article walks through a ThinkLink Edge (TKE) deployment in the order it actually happens. The focus is not the install command — it is the set of things that are usually discovered after the install, and that should have been settled before the machine was ordered.

1. Before You Buy Anything: Three Questions That Decide Whether You Need TKE

ThinkLink ships in three deployment forms: public-cloud SaaS (Cloud), self-hosted on a local server (TKE / ThinkLink Edge), and embedded inside a gateway (TKG). All three share the same thing models, RPC definitions and trigger logic, and assets can be migrated between them. That is what makes it safe to defer the decision — up to a point.

Dimension	Cloud	TKE (Edge)	TKG (in-gateway)
Where it runs	Public-cloud SaaS	Local server / industrial PC, self-hosted	Inside a ManThink gateway (e.g. GDO51 / GDI51)
Device ceiling	1,000 (free, permanently)	1,000	100
Data throughput	~100k messages/day	No stated ceiling	~10k messages/day
Reference hardware	Nothing to buy	8-core / 8 GB / 64 GB storage	Integrated (GDI51 has 32 GB eMMC)
Connectivity	Requires public internet	Local, runs offline	Local, no public internet needed
Best fit	Evaluation, small pilots	Data localisation, mid-to-large enterprises, private networks	Small private deployments, brownfield retrofits, no extra server

Three questions to answer first:

Do you actually need TKE? Under 100 devices and under 10k messages a day, TKG embeds the network server directly in the gateway — no extra server, no server procurement cycle. A great many "data must not leave the plant" requirements are really about not pushing production data out through a public internet egress, and TKG satisfies that at a completely different cost structure.

Which side of 10k messages/day are you on? That line separates TKG from TKE. 1,000 devices reporting every 10 minutes is 144,000 messages a day — above Cloud's reference density and far past TKG. 50 meters reporting hourly is 1,200 a day, which TKG handles comfortably.

Who owns this machine afterwards? TKE is a standing operational commitment: OS patches, Docker engine, seven containers, certificate renewals, backups. If the customer's IT department has not explicitly accepted ownership, you have created an unowned server, usually discovered in year two when the disk is full.

2. Hardware Selection: x64 Is a Hard Constraint, Not a Recommendation

The official documentation carries two different statements of TKE's hardware requirements, and they do not agree. Worth laying out before you commit budget.

Statement A (product comparison table): reference hardware 8 cores / 8 GB RAM / 64 GB storage, minimum 2 cores and 2 GB, architecture listed as ARM64 / x64.

Statement B (Docker deployment manual; install flow updated 2026-09-11, TLS section updated 2026-10-22):

Item	Requirement
Privileges	root (install commands use sudo)
CPU architecture	x64 only (x86_64 / amd64), minimum 2 cores
RAM	minimum 4 GiB
Disk	minimum 20 GiB free on the filesystem holding `/opt`
Network	HTTPS access to `package.think-link.net` for online install; the offline target needs no internet
Explicitly unsupported	ARM, ARM64, 32-bit x86

The two statements disagree on three points: 2 GB or 4 GB of RAM, 64 GB or 20 GB of disk, and — most consequentially — whether ARM works at all.

Follow statement B. Three reasons:

Statement B comes from the deployment manual itself and is what the installer actually checks against; failing it terminates the install. Statement A is a summary line in a comparison table.
Statement B is the stricter constraint. Seven containers run concurrently — EMQX, the NS bridge, PostgreSQL, Redis, ThinkLink, ThinkOne and MinIO. Two gigabytes leaves no headroom at that scale.
Statement B explicitly lists ARM, ARM64 and 32-bit x86 as unsupported, and separately notes the restriction applies to both the one-line online install and the scripted offline install. Wording that specific usually comes from having tried it.

This constraint collides head-on with domestic-CPU mandates. Chinese CPUs split into two camps:

Camp	Representative parts	Works with TKE?
x86	Zhaoxin KX-6000/KX-7000, Hygon 3000/5000 series	Yes — architecture is compatible
ARM	Phytium FT-2000/4 and D2000, Kunpeng 920, Rockchip RK3568/RK3588	No — incompatible

If a localisation mandate lands on the ARM camp, TKE should be ruled out during selection, not after the machine arrives and uname -m prints aarch64. The x86 camp works directly — Hygon 3350 (8 cores / 16 threads at 3.0 GHz) is x86_64.

Indicative pricing collected from public channels in October 2026:

Configuration	Purpose	Indicative price
4U rackmount, i5-6500U / 8 GB / 1 TB	Proof of concept (2 cores, sitting exactly on the minimum)	~$477 (¥3,200)
Industrial PC, Hygon 3350 (8C/16T) / 16 GB / 1 TB SSD	Recommended for production	~$1,550–1,700 (¥10,400–11,400)
Same, with domestic OS licence	Localisation-mandate projects	~$1,950 (¥13,100)

The first tier is a POC machine only. The i5-6500U is two cores / four threads, exactly the stated minimum; CPU becomes the bottleneck before the disk does.

3. The Disk Calculation: 20 GiB Is the Entry Ticket, Not the Plan

The 20 GiB check is the installer's admission gate. Real consumption comes from three sources.

Seven container images. The offline bundle accepted on 2026-09-11 for version 2.00.062 is about 2.45 GB, holding the application archive, the Compose file and seven image archives — nine files total. Later versions will differ.

Database growth. At 1,000 devices reporting every 10 minutes, that is 144,000 rows a day. At roughly 1 KB per row including indexes, about 144 MB/day, or ~52 GB a year. Add PostgreSQL WAL, index bloat and history-query overhead and the usual practice is to provision two to three times that.

MinIO object storage. Reports and images live in the Docker named volume minio_data. This swings wildly depending on whether the business generates reports and how often.

Sum them and 20 GiB covers a few months. Go to a 1 TB SSD for production. The price delta sits in the table above and is trivial against total project value; the alternative is an online capacity expansion in year two.

One detail that is easy to miss: object files live in a Docker named volume, so routine backups must cover that volume; backing up the /opt directory alone does not substitute for object data. A backup script that only walks a directory path will silently lose every report file.

4. Port Planning: "Not Leaving the Plant" Is Not the Same as "Not on a Network"

This is the section worth reading twice. On-premises deployment solves data residency. A default install then opens a full set of ports on the host, and a meaningful share of them are cleartext.

Complete the HTTP install first, then configure HTTPS with tkl-tls 2.0.0 — that is the documented order. Host inbound ports:

Port	Protocol	Purpose	Notes
80 (or 8080)	TCP	ThinkLink web / API over HTTP	Original entry; if 80 is taken the installer interactively offers 8080; retained after TLS
443	TCP	ThinkLink web / API over HTTPS	Enabled once tkl-tls 2.0.0 configures the in-container Nginx
1700	UDP	LoRaWAN GWMP gateway uplink	Open per gateway access needs
1883	TCP	Device MQTT (cleartext)	Open per device access needs
8883	TCP	Device MQTTS	Not published by default; configure and verify separately in EMQX
8083	TCP	MQTT over WebSocket	Open per client needs
8084	TCP	MQTT over WSS	Path `/mqtt`; requires its own certificate
18083	TCP	EMQX dashboard over HTTP	Retained; not automatically upgraded to HTTPS
18084	TCP	EMQX dashboard over HTTPS	Enabled by tkl-tls 2.0.0
9000	TCP	MinIO S3 API	Restrict source addresses
9001	TCP	MinIO console	Trusted administrator networks only

Details that belong in the plan:

Port conflicts are handled inconsistently. If 80 is taken, the installer asks whether to use 8080 and leaves the occupying service alone. But if 9000 or 9001 is taken, the installer stops outright and will not pick an alternative. A target machine already running another storage service will stall mid-install.

5432 and 6379 never need to be exposed. PostgreSQL and Redis ports are container-internal only.

Management HTTPS is not device MQTTS. tkl-tls produces 443 and 18084. Device-side 8883 and 8084 are unpublished by default and need certificates uploaded in EMQX, mappings opened and connectivity verified. Replacing the certificate in the management UI does not replace device listener certificates — those are two separate configurations.

An open port is not an enabled TLS listener. Worth copying the manual's reminder straight into the acceptance sheet.

The EMQX console at 18083 stays HTTP. The HTTPS console is 18084; the old entry is retained. Locking down 18083 while forgetting 18084 accomplishes nothing.

5. On-Premises Deployment ≠ Regulatory Compliance

This is the most common misreading of "data must not leave the plant."

Moving the platform inside the plant addresses storage location. The path from sensor to platform is still network transmission, still subject to whatever the applicable rules require of transmission.

China's Interim Measures for Data Security Management in the Industry and Information Technology Sector (MIIT Network Security Circular No. 166, issued 2022-12-08, effective 2023-01-01) classifies sector data into three tiers — general, important and core — and states in Article 17:

Data processors shall formulate security policies and adopt protective measures based on the type, level and application scenario of transmitted data. When transmitting important data or core data, they shall adopt verification technology, cryptographic technology, secure transmission channels or secure transmission protocols.

Read that against the port table above. Under a default install, device MQTT runs cleartext on 1883, HTTP runs on 80, and MinIO's S3 API on 9000. If this system carries data classified as important, on-premises deployment alone does not satisfy Article 17 — the transmission channels have to be closed as well, meaning web/API on 443 and device MQTT on 8883.

The Network Data Security Regulations (State Council Decree No. 790, published 2024-09-24, effective 2025-01-01, nine chapters and 64 articles) establishes the classification-and-grading regime one level up, with a dedicated chapter on important data.

Two further clauses land on concrete operations:

Article 15: storing important and core data requires secure storage using verification and cryptographic technologies, plus data disaster-recovery backup and storage-media security management, with periodic data recovery testing.
Article 25: processors must log data processing, permission management and operator actions, retaining logs for no less than six months.

For European readers the pressure arrives from a different direction. The EU Data Act's design obligation for data access (Article 3(1)) took effect on 2026-09-12, with cloud switching charges falling to zero on 2027-01-12. Different instrument, same structural conclusion: the ability to move a deployment — including moving it onto your own hardware — is becoming a compliance matter, not an architecture preference.

The three clauses together form a chain: local deployment is step one, TLS is step two, backup and log retention are step three. Declaring compliance after step one is what gets caught in an audit.

6. Two Install Paths: Online One-Liner and Scripted Offline

Online

On a connected server, no arguments needed:

curl --tlsv1.2 --tls-max 1.2 -fsSL https://package.think-link.net/install.sh | sudo bash

The installer: detects OS, CPU, RAM, disk and ports → installs Docker on supported systems (reusing any working Docker) → downloads the application archive, the Compose file and seven image archives (nine files) → installs to the target directory, loads images and starts Compose → checks ThinkLink HTTP, MinIO readiness and bucket initialisation → records version and access information.

MinIO creates a private bucket named thinklink on first start.

Scripted offline

The documentation summarises it as "download online → transfer and verify → install offline."

Step one, on a connected machine. The download mode must run from a local script file, never through curl | bash, because the bundle has to carry the same complete installer:

curl --fail --silent --show-error --proto '=https' \
--tlsv1.2 --tls-max 1.2 --connect-timeout 10 --max-time 60 \
https://package.think-link.net/install.sh -o thinklink-install.sh

bash thinklink-install.sh --help
bash thinklink-install.sh --download-only ./thinklink-offline

Run --help first and confirm it lists --download-only, --verify-only and --offline. The target directory must not yet exist and its parent must; do not mkdir it beforehand.

The delivered directory holds 13 checksummed files:

File	Role
application.tar	Application archive
docker-compose.yml	Compose definition
tkl-emqx.tar / tkl-nsbrg.tar / tkl-postgres.tar	EMQX, NS bridge, PostgreSQL images
tkl-redis.tar / tkl-thinklink.tar / tkl-thinkone.tar	Redis, ThinkLink, ThinkOne images
tkl-minio.tar	MinIO image
install.sh / install-offline.sh	Installer scripts
release.json	Release id, version, channel, architecture
SHA256SUMS	Covers 9 artifacts, 2 scripts, the version record and the readme
README.txt	In-bundle notes

Step two, transfer and verify. Move the directory intact — it is created with mode 0700 and should stay read-restricted afterwards. On the target:

cd thinklink-offline
bash install.sh --verify-only .

This mode needs no root, no Docker and makes no network requests. It checks file integrity, manifest paths and version format, and only proceeds if all pass. SHA-256 verifies transfer integrity; it is not a publisher signature and does not independently prove provenance — a candid note in the manual, and a reminder that supply-chain trust still rests on the delivery channel.

Step three, install. Run sudo bash install-offline.sh in the bundle directory, adding --yes for unattended runs (it skips only the final confirmation prompt, not verification or port checks).

The offline target must already have Docker Engine and Docker Compose V2, because the bundle does not include Docker or OS dependencies. Check first:

uname -m
sudo docker version
sudo docker compose version

uname -m must print x86_64. Anything else: stop.

Three limits of the offline path

New installations only — no automatic upgrade, no rollback on failure. If it detects an existing install or leftover data, it leaves the scene intact for you to investigate rather than cleaning up and retrying. Upgrades need new artifacts, a backup and a version-matched upgrade plan.
Do not mix download batches. The package service checks upstream at 00:00 Beijing time daily and updates artifacts. Mixing batches produces OFFLINE_IMAGES_MISSING — Compose and images out of sync.
No resumable downloads across processes. A failure means re-downloading the whole 2.45 GB. On an expired URL or single-file failure, the script refreshes the address within the same session and retries once.

7. The One Red Line When Running Alongside Cloud

Most projects pass through a transition period with a foot in both camps — legacy devices in the cloud, new devices on-premises, both live.

The documentation is unambiguous:

Do not enable the same LoRaWAN device profile on two platforms at once. If TKE and the cloud platform both respond to Join or Confirm messages, join failures and downlink conflicts can result. When switching platforms, disable or delete the profile on the one you are not using.

This is a functional constraint, not a performance tip. A Join Request is forwarded to every NS registered for that DevEUI. Both answer with a Join Accept; the device accepts one, but the other NS now believes the device joined and holds frame counters — subsequent downlinks go to the wrong path.

During transition, the profile is enabled on exactly one side. Not "both on, whoever answers first."

8. Cloud → Edge Migration: Three Traps in the Excel Import/Export

ThinkLink moves bulk data through Excel across six module types: device configurations, LoRaWAN profiles, thing models, RPC commands, linkage/trigger models and device templates. The workflow is identical on Cloud, TKE and TKG — the only difference being that TKE/TKG have their own local admin account, unrelated to the cloud one.

In the cloud, open the target module (e.g. LoRaWAN Profiles)
Select the entries to sync (none selected = export all)
Click Export and download the generated spreadsheet
Repeat 2–3 for each data type (thing models, RPC commands, …)
Switch to TKE and open the matching module
Click Import and choose the spreadsheet
Confirm the import completed without errors
Importing public models requires logging in as admin

Three traps:

Trap one: DevEUI is globally unique, so cross-organisation migration is delete-then-import. A given DevEUI belongs to one organisation within a platform. Moving a profile from organisation A to B requires deleting it in A first; otherwise the import fails outright.

Data type	Delete first?	Why
LoRaWAN Profiles	Yes	DevEUI is globally unique
Thing models / RPC commands / device templates	No	Same ID means overwrite; not uniqueness-constrained

Trap two: a matching ID means full overwrite, and it cannot be rolled back. The rule is "create if the ID is absent, overwrite completely if present." That is a replacement, not a merge. Stale field values in the spreadsheet will overwrite live configuration on the target.

There is exactly one mitigation: export first, before importing, and keep that spreadsheet as the backup. Validate format on a small batch before the first large import.

Trap three: there is no undo. With a backup, re-import it. Without one, rebuild the configuration by hand. Review the ID column row by row so the file contains only what you intend to create or update.

9. Backups: Three Layers That Do Not Substitute for One Another

Layer	Location	Method
Configuration and install record	Install directory under `/opt`	File-level backup
Database	PostgreSQL container volume	Volume snapshot or logical dump
Object files	Docker named volume `minio_data`	Volume-level backup

Backing up /opt alone does not substitute for object data. A container restart preserves existing buckets and objects; host disk failure does not.

Article 15 of Circular 166 requires disaster-recovery backup and periodic recovery testing. Note the second half — a backup that has never been restored is a hypothesis. One way to exercise the whole chain during acceptance is generating and downloading a report:

sudo docker compose -f exec -T minio /thinklink-minio check-ready

That command checks whether the image's built-in initialisation completed; pair it with a container status check.

10. Error Codes Worth Recognising

The manual lists the full set. These are the ones that surface during deployment:

Message	Meaning and handling
`OFFLINE_OUTPUT_EXISTS`	Download directory already exists — pick one that does not; do not overwrite the old bundle
`SCRIPT_FILE_REQUIRED`	Download mode must run from a local script file, not `curl \
{% raw %}`ARTIFACT_DOWNLOAD_FAILED`	Check network and disk space, re-download the whole set
`DOWNLOAD_REFRESH_INVALID`	Version or artifacts changed while refreshing — re-download the full bundle
`OFFLINE_BUNDLE_INVALID` / `OFFLINE_CHECKSUM_FAILED`	Re-transfer the complete directory; do not edit the manifest to bypass
`OFFLINE_DOCKER_REQUIRED`	Install offline dependencies, start Docker, verify Compose V2
`OFFLINE_EXISTING_INSTALL`	Existing install or data present — prepare a backup and upgrade plan first
`PORT_IN_USE` / `ALTERNATE_PORT_IN_USE`	Resolve the conflict, arrange a usable port, retry
`OFFLINE_IMAGES_MISSING`	Compose and images out of sync — supply a matching full bundle
`HEALTH_CHECK_FAILED`	Check container status and logs; preserve install data while investigating

Two for day-to-day work:

sudo docker compose -f ps
sudo docker compose -f logs

Check logs for connection strings and credentials before sharing them externally — a reminder the manual makes on its own.

11. Acceptance Checklist

In the order of this article, a TKE deployment ready to hand over:

#	Item	Pass criterion
1	`uname -m` prints `x86_64`	Non-x64 fails outright
2	CPU ≥ 2 cores, RAM ≥ 4 GiB, `/opt` ≥ 20 GiB	Production: 8 cores / 16 GB / 1 TB
3	Pre-flight port check on 80/8080, 9000, 9001, 1700, 1883	A 9000/9001 conflict aborts the install
4	All seven containers running	`docker compose ps`
5	Private MinIO bucket ready, anonymous access refused	`check-ready` plus an anonymous access attempt
6	Web/API on HTTPS 443, EMQX console on 18084	tkl-tls 2.0.0
7	Device MQTT on 8883 (where required)	Configured and verified separately in EMQX
8	MinIO 9000/9001 reachable only from trusted networks	Firewall rules
9	No device profile enabled on both cloud and TKE	Profile inventory cross-check
10	Export taken before import	Backup file retained
11	Backup scope covers the `minio_data` volume	Backup script review
12	One recovery test completed	Recovery drill record
13	Default passwords changed (ThinkLink / EMQX / MinIO)	Business client configs updated to match
14	Full offline bundle + `release.json` + `SHA256SUMS` retained	Version traceability

Item 5's "anonymous access to the private bucket refused" was explicitly covered in the vendor's own 2026-09-11 acceptance record, and it belongs on your checklist too. A private bucket that is anonymously readable is every report file sitting in an internal share.

12. Closing

"Data must not leave the plant" is a requirement about storage location, and it triggers three consequences: you buy the machine, you close the transmission channels, and you run the backups. Only the first of those is a procurement problem.

Two points this article has argued repeatedly:

On-premises is not the same as compliant. Article 17 of Circular 166 requires secure transmission channels or protocols for important data. A default TKE install runs MQTT in cleartext on 1883 and HTTP on 80. tkl-tls is not an optional hardening step; it is what closes that clause.

Confirm the x64 constraint before the purchase order. The vendor's own documentation carries two conflicting statements about TKE's hardware requirements, and they disagree on whether ARM works. Taking the deployment manual as authoritative: it does not. If a localisation mandate has already settled on Phytium or Kunpeng, raise it at proposal stage rather than when uname -m prints aarch64.

TKE's value is that it bundles the network server, thing models, trigger logic, alarms and object storage into one Compose command while preserving a migration path to and from both the cloud and the in-gateway form. The price is that someone now owns it. Deciding who, before buying anything, matters more than the spec sheet.

Next in the series (Issue 24): the data is local; now let the rest of the building read it — BACnet/IP and Modbus TCP integration on ThinkLink, from field mapping to commissioning with YABE.

Sources

ThinkLink documentation, Docker Deployment (TKE) — install flow updated 2026-09-11, TLS and port notes updated 2026-10-22: https://www.think-link.net/docs/zh/QuickStart/Deployment/ThinkLinkDocker.html
ThinkLink documentation, ThinkLink (TKL) Introduction: https://www.think-link.net/docs/zh/QuickStart/ThinkLinkIntroduction.html
ThinkLink documentation, Batch Data Management Guide: https://www.think-link.net/docs/zh/AN/BatchDataManagementGuide.html
ThinkLink documentation, ThinkLink in Gateway (TKG): https://www.think-link.net/docs/zh/QuickStart/Deployment/ThinkLinkGateway.html
MIIT, Interim Measures for Data Security Management in the Industry and Information Technology Sector, Network Security Circular No. 166, effective 2023-01-01
State Council, Network Data Security Regulations, Decree No. 790, effective 2025-01-01

The Last Mile of Industrial IoT: An LPWAN Technology Selection Analysis

manthink — Sun, 20 Sep 2026 08:18:51 +0000

Series: ManThink "LoRaWAN Technical Reading" Issue #15 · Industry Trends, Part 5
Keywords: Industrial IoT, last mile, LPWAN selection, LoRaWAN, NB-IoT, private LoRa, DTU, RS-485, Modbus, brownfield retrofit

Opening: A Number Mismatch Everyone Misses

One statistic from the 2026 industrial communication market circulates widely: HMS Networks' twelfth consecutive annual analysis shows Industrial Ethernet accounting for 79% of newly installed nodes worldwide, fieldbus dropping to 14%, and wireless holding steady at 7%.

Many conclude from this that the industrial communication war is over and Ethernet has won.

But the same research bodies (LNS Research, ARC Advisory, and McKinsey's 2025 manufacturing benchmarks) offer another number: roughly 70% of installed industrial control assets have been in service for more than 15 years, and a meaningful share still speaks Modbus RTU over RS-485 — using a 1998-vintage protocol to report data to a controller whose vendor stopped patching firmware decades ago.

Put the two numbers side by side and the structural mismatch of industrial IoT becomes visible:

At the new-node level, Ethernet has indeed won (79%);
At the installed-base level, serial and fieldbus remain dominant (70% of assets older than 15 years, PLC lifespans of 10–20 years, process-industry pumps, transmitters, and valves lasting 20–30 years, and the average age of US manufacturing equipment approaching 20 years).

That is the true nature of the "last mile" problem: it is not "the last stretch of distance" — it is "the last batch of un-digitized assets." These assets share three properties:

Cannot be removed — the injection molder on the line, the compressor in a pharmaceutical cold chain, the pump station at the water plant: removal means downtime, and one unplanned hour on an automotive subassembly line costs five figures in scrap alone;
Cannot be modified — a 1998 PLC may carry qualification documents that took a customer audit six months to obtain. Re-flashing it is not on the table;
Should not be replaced — the equipment itself runs fine. Replacement means paying for an entire machine to serve the accessory need of "getting data online."

So the technology selection question for the industrial IoT last mile was never "which wireless technology is more advanced," but "which retrofit route can bring installed assets online under those three constraints."

This article unpacks the problem: first the true shape of the installed base, then a horizontal comparison of candidate technologies, then a quantified look at four classes of industrial-environment challenges, and finally a selection decision tree you can follow.

1. Know Your Opponent: Why the Installed Base Cannot Be Eliminated

1.1 Modbus: Modest Share, Irreplaceable Position

The 2026 protocol market-share data is misleading. Modbus TCP holds 5% of new industrial Ethernet nodes, and Modbus RTU holds 3% of new fieldbus nodes — apparently "a declining legacy protocol."

But note two facts.

First, those shares have been "stable" for years. Across HMS's historical reports, Modbus RTU's 3% is the flattest curve in the fieldbus category. It plays the role of the "universal connection layer": unlike PROFINET or EtherNet/IP, which mainly serve specific vendor ecosystems, Modbus appears in equipment from virtually every major automation brand. One fact confirms its standing in cost-sensitive segments: in small-PLC and sensor access scenarios, Modbus's share has long hovered around 80%, and a Modbus driver costs roughly one-fifth of an OPC UA driver per device.

Second, the installed base matters far more than new-install share. Equipment lifecycles dictate protocol survival: PLCs 10–20 years, process equipment 20–30 years. Today's 79% Ethernet share of new nodes will not become the "installed majority" until 2036–2046; meanwhile, the tens of millions of Modbus devices still running today will keep serving for another decade or more.

This creates a powerful lock-in effect: new equipment must be compatible with existing Modbus networks, and the existence of those networks makes Modbus the natural choice for new projects. Manufacturers do not replace stable, running systems because a protocol is "outdated" — an upgrade means coordinating a line-wide replacement or maintaining parallel communication infrastructure, both expensive and risky.

1.2 RS-485: The Evergreen Physical Layer

Beneath Modbus RTU sits RS-485, whose longevity comes from three engineering properties:

Property	Value / Behavior	Engineering Meaning
Distance without repeater	1,200 m	Far beyond RS-232 (15 m); covers plant-level spans
Differential signaling	Common-mode noise rejection	First choice for high-EMI plant floors
Bus topology	One master, many slaves	Lowest cabling cost of any industrial bus
Typical slave count	Dozens on one bus	One twisted pair serves a whole metering cabinet

Electricity meters, water meters, heat meters, flow meters, PLCs, variable-frequency drives, environmental monitors, industrial controllers — nearly every industrial metering and control device offers RS-485 terminals. That is not technological inertia; it is three decades of proven reliability.

1.3 The Communication Dilemma of the Installed Base

The problem is "access." A typical wired architecture looks like this:

RS-485 device → Data collector → Industrial switch → Server → Management platform

This architecture works fine for "in-building, newly built, centralized" scenarios, but costs spiral out of control in four situations:

Across floors / buildings / campuses: communication cable + trays + conduit + labor — communication infrastructure becomes a major cost line;
Operational sites: pulling new cable through a running factory means downtime windows and hot-work permits;
Expansion: every new monitoring point adds cable, and maintenance complexity compounds as the network grows;
Remote accessibility: RS-485 is a local protocol by birth; going cloud requires stacking an entire additional system.

That is the precise shape of the last-mile problem: on the device side, an RS-485 bus that runs reliably for 1,200 meters; on the platform side, a modern cloud and historian; and in between, the stretch of road that "carries serial data to the cloud" — the real bottleneck.

2. Candidate Technology Review: The Real Boundaries of Six Routes

The candidates that actually get serious evaluation for that middle stretch are six: private LoRaWAN, NB-IoT, private LoRa (data radios), 4G/5G DTUs, Wi-Fi/BLE, and Wi-SUN. The first four are mainstream; the last two have clear boundaries in industrial settings.

2.1 Six-Dimension Comparison Table

Dimension	Private LoRaWAN	NB-IoT	Private LoRa Radio	4G/5G DTU	Wi-Fi/BLE	Wi-SUN
Spectrum	Unlicensed Sub-GHz	Licensed (operator)	Unlicensed Sub-GHz	Licensed (operator)	2.4/5 GHz unlicensed	Unlicensed Sub-GHz
Network ownership	Self-owned	Operator	Self-owned	Operator	Self-owned	Self-owned
Coverage	5–15 km (site-dependent)	Depends on operator lighting	Point-to-multipoint 3–10 km	Depends on cellular	30–100 m	Several km, Mesh
Power adaptability	10-yr battery or DC	Battery months–years	Requires stable DC (9–30V)	Requires stable DC	High power draw	Low power
Per-message size	Tens of bytes	Hundreds of bytes–KB	Tens of bytes	MB-scale	MB-scale	Hundreds of bytes
Cost structure	CAPEX (one-time gateways)	OPEX (SIM fee × devices × years)	CAPEX (module-level)	OPEX (data plan)	CAPEX	CAPEX
Protocol adaptation	Standard + DTU pass-through	CoAP/MQTT	Serial pass-through (any protocol)	TCP/UDP pass-through	Full IP stack	6LoWPAN
Interference immunity	CSS spread spectrum, strong	Protected licensed band	Implementation-dependent	Licensed band	Congested 2.4G	Strong
Typical role	Campus/plant sensor network	Nationally scattered assets	Point-to-point link replacement	Bulk data / video	High-bandwidth short range	Metering Mesh (North America)

2.2 Route by Route

Private LoRaWAN — the advantages are threefold "ownership": unlicensed spectrum, self-built network, sovereign data. The gateway sits on your own site; coverage is defined by you. It does not depend on whether an operator has lit up NB-IoT on a given mast, and there is no risk of devices going dark en masse because an operator sunsets a service (a real failure category in NB-IoT deployments). The price: up-front CAPEX and gateway operations responsibility that stays with you. CSS modulation gives it natural resistance to narrowband interference, and the Sub-GHz band diffracts around concrete and metal far better than 2.4 GHz.

NB-IoT — the advantage is "no network to build": you use operator infrastructure directly, which suits assets scattered nationwide (shared-bike locks, manhole covers, cross-border logistics). The price: a per-SIM annual fee (OPEX that grows linearly with fleet size), coverage entirely dependent on the operator (indoor, basement, and remote plant areas are often unlit), and service-continuity risk over the device lifecycle. In industrial scenarios where devices cluster on your own site, NB-IoT's advantages are mostly unusable while its disadvantages are fully exposed.

Private LoRa radios (data radios) — the difference from LoRaWAN is the absence of a standard protocol stack: point-to-multipoint transparent pass-through with custom protocols. It suits "stable power, no cellular coverage, private protocol" scenarios, such as water-quality monitoring at a mountain fish farm (24V power available, no cellular signal, Modbus data across 3 km). The price: none of LoRaWAN's standard ecosystem (NS, platforms, certified device pool), with management costs rising at scale.

4G/5G DTUs — the bandwidth route. Tower-crane video monitoring and AGV bulk telemetry can only go here. Using it for metering-grade small messages is economically irrational: you pay for megabytes and transmit tens of bytes.

Wi-Fi/BLE — high-bandwidth short range, suited to AGVs/AMRs and handheld terminals. In industrial sensing the problems are poor 2.4 GHz penetration, high power draw, and the cost of dense AP deployment. A pharmaceutical cold-storage lesson: the insulation is thick metal plate plus polyurethane foam; a Wi-Fi solution attenuated badly inside the chamber and dropped constantly; the final fix was 470 MHz LoRaWAN, where one gateway penetrated 20 cm of cold-storage insulation and covered the entire campus.

Wi-SUN — Sub-GHz Mesh with an installed-base advantage in North American metering, but its ecosystem and device selection are far smaller than LoRaWAN's in industrial scenarios elsewhere; it usually enters evaluation only when a customer explicitly specifies it.

2.3 A Quick-Reference Conclusion Table

Your Scenario	First Choice	Rationale
Devices clustered on your own site; metering/status small messages	Private LoRaWAN	Sovereign coverage, no SIM fees, CSS interference immunity
Assets scattered nationwide, no fixed site	NB-IoT	Trade self-built cost for operator coverage
Point-to-point 3–10 km, stable power, private protocol	Private LoRa radio	Flexible pass-through, no platform dependency
Video / large files / high-frequency waveforms	4G/5G	The only bandwidth answer
Already a nationwide metering Mesh (North American legacy)	Wi-SUN	Legacy continuity

3. Four Classes of Industrial-Environment Challenges: Separating "Works" from "Works for Ten Years"

A selection table only answers "which route." The cruelty of industrial sites is that the numbers on a datasheet and the site three years later are different things. Four challenge classes decide equipment-selection survival.

3.1 Metal and Electromagnetics: Where 15% Packet Loss Comes From

The three least wireless-friendly things on an industrial site: metal structures (reflection, blockage), VFDs and motors (EMI), and dense radio equipment (co-channel interference).

A mining case provides representative measured data: in large-scale mining and petrochemical facilities, commercial off-the-shelf gateways in plastic enclosures showed a 15% packet-loss rate, causing frequent manual resets and on-site technician visits; after switching to a solution with optimized RF shielding and industrial-grade components, packet loss fell to 0.8%, annual downtime dropped from 48 hours to 4, and per-unit annual maintenance cost fell from $1,200 to $150.

LoRaWAN's confidence in such environments comes from the technical layer:

CSS (Chirp Spread Spectrum) modulation spreads signal energy across the whole bandwidth, giving natural immunity to narrowband interference (VFD harmonics, motor arcing) — precisely why it remains viable in "electrically dense" environments;
The Sub-GHz band (470 MHz in China, 868 MHz in Europe) diffracts and penetrates significantly better than 2.4 GHz;
ADR lets weak spots automatically retreat to higher SF for link margin, at the cost of longer airtime;
FEC lets receivers repair damaged packets.

But three disciplines still apply: keep antennas off metal longitudinal axes, stay more than 30 cm from reflective surfaces, and do frequency planning across multiple gateways. In high-EMI environments, consider actively pushing SF down to 7/8 — sacrifice extreme range for shorter time-on-air and lower interference exposure.

3.2 Temperature: What Freezes and Cracks at -80°C Is Not the Sensor

The conventional industrial temperature requirement is -40°C to +85°C, and that number alone is not hard to meet (standard industrial-grade component binning). The traps are in the details:

A 2,000 m² pharmaceutical cold-storage project (three -80°C ultra-low freezers plus one 2–8°C cold room, holding over ¥50M of vaccines and blood products) learned this the hard way: on day one of the LoRaWAN deployment, data from the -80°C chamber was still unstable. Investigation showed the problem was not radio but the rubber jacket of the probe wiring, which hardened and embrittled at ultra-low temperature, causing intermittent contact. The fix: replace with Teflon-jacketed low-temperature shielded cable and pot every terminal with sealant.

The general lesson: cold's failure points are usually in "accessories" — cable, connectors, battery — not the chips on the main board. At selection time, audit wiring, terminals, and packaging with the same rigor as the host. Placement matters too: probe into the chamber, host outside — protecting both measurement accuracy and battery performance in the cold.

3.3 Power Supply: AC Wide-Voltage Is an Underrated Differentiator

Industrial-site power is far dirtier than assumed: voltage fluctuation on shared supplies, harmonics fed back by VFDs, maintenance outages. "Unexpected gateway/DTU reboot interrupting packet forwarding" is a high-frequency failure class, and diagnosing it is extremely expensive at unattended sites.

Here an important selection fork appears — the DTU's power format is effectively doing scenario segmentation for you:

Power Format	Fitted Scenario	Typical Product Form
AC 85–270V wide voltage	Inside power/metering cabinets, drawing site AC directly	Rail-mounted DTU
DC 5–24V	Low-voltage cabinets, instrument boxes	Compact rail DTU
Battery (Li-SOCl₂, 10,800 mAh)	Remote points with no supply	Battery DTU

AC wide voltage (85–270V) means the device can hang inside a power distribution cabinet in any country without a separate adapter — in retrofits, that is the difference between "installable" and "not installable." For battery versions, audit sleep current (industry level ≤5–15 μA) and battery internal-resistance degradation in the cold.

3.4 Operations Inaccessibility: Remote Manageability Is the Industrial-Grade Threshold

Large numbers of industrial points are "install and never visit." Robustel's summary of industrial gateway failure modes is apt: many gateway failures are not caused by the "outdoors" but occur indoors in apparently protected locations — high temperature in metal cabinets, condensation during start/stop cycles, shared-supply fluctuation, motor interference, signal attenuation through the metal cabinet, restricted maintenance access.

That turns remote management from a nice-to-have into a survival requirement. At minimum: remote parameter configuration (via the NS, no site visit), remote firmware upgrade (FUOTA), disconnect-reconnect with data buffering and retransmission (for metering continuity), and remote health visibility (battery level, signal quality, module self-check).

4. The Selection Decision Tree: Five Questions to Fix the Route

Converging the preceding analysis into five questions, answered in order:

Q1. What is the data profile?
    ├─ Video / large files / high-frequency waveforms ───→ 4G/5G DTU. End of analysis.
    └─ Metering / status / alarms (small messages) ───→ Q2

Q2. Are devices clustered or scattered?
    ├─ Scattered nationwide, no fixed site ───────────→ NB-IoT (use operator coverage)
    └─ Clustered on your own site / campus ───────────→ Q3

Q3. Is there deep cellular coverage on site (indoor/basement/metal plant)?
    ├─ Yes, and customer accepts OPEX ───────────────→ NB-IoT viable; recheck at Q4
    └─ No, or network sovereignty required ──────────→ Private LoRaWAN; proceed to Q4

Q4. What interface do the target devices have?
    ├─ RS-485/Modbus, M-Bus, 4-20mA, DI/DO (installed wired assets)
    │    └─→ DTU route: keep original devices, replace only the last hop → Q5
    └─ New sensor points
         └─→ Choose native LoRaWAN sensors directly → Q5

Q5. What is the power condition at the points?
    ├─ Power/metering cabinet (AC available) ────────→ Rail DTU (AC wide voltage)
    ├─ Low-voltage cabinet (DC 5–24V) ──────────────→ Compact rail DTU
    └─ No supply ───────────────────────────────────→ Battery DTU (audit sleep current
                                                        and cold performance)

The tree's three pivotal judgments:

Q2 is the watershed: the distribution shape of devices (clustered vs. scattered) determines the route earlier than any technical parameter. Most industrial scenarios fall on the "clustered" side — which explains why industrial private networks are LoRaWAN's fastest-growing segment.
Q4 is where the money is: if the target devices are RS-485 installed assets, the DTU route expands your sensor sourcing from "LoRaWAN-interface sensors only" to "any wired sensor" — far cheaper, far more options, and not one line of code changes on the original equipment.
Q5 is the final gate to deployment: power format determines the specific model and the installation workload (whether you must provision a separate power supply for the DTU).

5. ManThink's Answer: The DTU Route and EdgeBus

With the methodology covered, here is our own engineering answer. Since its founding in 2014, ManThink has focused on a single positioning: connecting the installed base — low-cost wireless retrofit of wired-interface field devices (RS-485, M-Bus, 4-20mA, 0-10V, DI). The output of that route is a complete DTU product line plus an edge-computing virtual machine that runs inside the DTUs.

5.1 Three DTUs Segmented by Power Condition

Parameter	KC11	KC25	KC21
Positioning	Rail-mounted industrial workhorse	2nd-gen compact rail	Battery-type remote points
Power	AC 85–270V wide voltage	DC 5–24V	4× ER14505 Li-SOCl₂ (10,800 mAh)
Interface	RS-485	RS-485	RS-485
Mounting	DIN rail	DIN rail	Wall-mount (PG7 gland)
Operating class	Class C	Class C	Class A (battery) / Class C (DC)
TX power	22 dBm	22 dBm	22 dBm
RX sensitivity	-142 dBm @SF12	-142 dBm @SF12	-142 dBm @SF12
Temperature	-40 to +85°C	-40 to +85°C	-40 to +85°C
Protection	IP53 (in-cabinet)	Aluminum enclosure	IP65 (outdoor)
Distinguishing feature	Compatible with all RS-485 protocols	Ultra-compact (69×25×25 mm)	Can power external sensors
Deployment scale	100,000+ units deployed	Current generation	Harsh points

The three models cover all three branches of decision-tree Q5: AC from the power cabinet with KC11, DC from the low-voltage cabinet with KC25, and no-supply remote points with the battery KC21 (IP65 outdoor protection, plus the ability to power external water/gas meters — saving a whole supply system).

All support the six regional standards — CN470/EU433/EU868/AS923/AU915/US902 — and connect to any standard LoRaWAN platform: ThinkLink, ChirpStack, or TTN. No lock-in at the gateway or platform layer — the fundamental difference from vendors of "complete closed systems."

5.2 EdgeBus: Why Protocol Adaptation Cannot Be Just "Configuration"

The deepest pit on the DTU route is not radio but protocol adaptation. On the surface, connecting a Modbus meter means configuring a slave address, register map, and data types. In real projects:

Electricity meters speak DL/T 645-2007, water/gas/heat meters speak CJ/T 188, imported instruments speak all manner of proprietary protocols — three address lengths (1/6/7 bytes), three frame formats, each with its own CRC;
You need COV (Change of Value): don't transmit when metering data hasn't changed — saving not just airtime but battery life;
You need threshold logic: report a temperature violation immediately, not at the next cycle;
You need data restructuring: split, scale, and structurally package multiple register values from one 485 frame.

ManThink's answer is EdgeBus (EB): an event-driven edge-computing virtual machine. You write collection logic in TypeScript, compile it to a few hundred bytes of binary, and run it low-power on a Cortex-M0-class MCU. Its runtime model is two periodic events:

Query event: periodically send commands to RS-485 sub-devices and fetch raw data;
Uplink event: periodically package processed data and send it via LoRaWAN.

EB natively supports Modbus (CRC checks, integer/float/BCD read-write), DL/T 645, CJ/T 188, and any custom protocol, and completes COV, alarm triggering, and data restructuring locally at the endpoint — with that logic pushed down to the device, uplink data volume, airtime consumption, and cloud-side parsing burden all fall together.

More important is the change in engineering workflow: EB code is debugged and upgraded entirely online. In real projects you can install the hardware on site first, then push the business logic via FUOTA (multi-bin block-wise, compressed low-power over-the-air upgrade) — decoupling field installation from software debugging. For retrofitting factories that cannot be stopped, this is decisive: hardware installation fits in one maintenance window; protocol adaptation is done slowly from the office.

5.3 A Chain Proven Across 100,000 Units

Assembling the full chain:

Installed RS-485 devices (meters / PLCs / transmitters, untouched)
    ↓ RS-485 / Modbus / DL/T645 / CJ/T188
DTU (KC11/KC25/KC21, EB VM runs protocol parsing & COV locally)
    ↓ LoRaWAN (CN470 private network, CSS interference immunity)
Gateway (GDI51/GDO51/GD61x, per indoor/outdoor and scale)
    ↓ Ethernet / Wi-Fi / 4G backhaul
NS + Platform (ThinkLink, or ChirpStack/TTN — no lock-in)
    ↓
SCADA / BMS / energy management / third-party platforms

The economics of this chain: installed wired assets see zero replacement; only the "last hop" wireless conversion layer is added. Compared with the "replace with native LoRaWAN sensors" route, per-point cost drops sharply; compared with the "replace whole machines" route, the cost differs by an order of magnitude. The KC11 alone passing 100,000 deployed units is the most direct evidence that this route has survived real industrial sites.

6. Five Common Misconceptions

Misconception 1: "79% of new nodes are Ethernet; serial is being phased out."
New-install share and installed base are two different statistical frames. With 70% of in-service assets older than 15 years and process equipment lifespans of 20–30 years, serial devices will keep serving on-site for another decade — "phase-out" is a 2040s topic. The last-mile problem exists precisely inside that time gap.

Misconception 2: "Operator networks are broad; just use NB-IoT on industrial sites."
"Broad coverage" means outdoor ground level. The places industrial assets live — inside power cabinets, basements, deep inside metal plants, remote sites — are exactly where deep cellular coverage is worst. The more practical problem: NB-IoT's OPEX model (SIM annual fee × device count × years) is a continuously growing bill at thousand-point scale, and service continuity over the device lifecycle is not under your control.

Misconception 3: "LoRaWAN capacity is insufficient for industrial point counts."
We did this math in Issue #10: a single gateway carries five-figure node counts at SF7 and hundreds at SF12. Industrial metering messages are "tens of bytes every 15 minutes" — the real bottleneck is coverage, not capacity. Coverage-starved points pushed to SF12 by ADR are the capacity killers, so well-placed gateways are themselves the most effective capacity upgrade.

Misconception 4: "A DTU is just a pass-through module; buy a cheap one."
Pass-through only moves bytes from serial to cloud. What decides project survival is protocol parsing (the address-length differences of DL/T645/CJ188), COV strategy (the key to battery life), FUOTA (the only way to fix logic defects when no one can reach the site), and wide-voltage power (whether it installs in a distribution cabinet). These capability gaps are invisible at selection and visible in year three. The mining case's 15% vs. 0.8% packet-loss gap and the $1,200 vs. $150 annual maintenance gap are the three-year ledger of "cheap off-the-shelf" versus "engineered product."

Misconception 5: "Wireless retrofit means touching the original system — too risky."
The opposite is true: the DTU route is the least invasive of all retrofit paths — original equipment untouched (no re-flashing, only a parallel connection onto the 485 bus), original control systems running as before, wireless layer independently overlaid. The real risk lives in routes that "modify the original system" — that is where qualification documents lapse, SIL ratings need re-assessment, and downtime windows appear.

7. A Closing Clarification

The industrial IoT last mile is often framed as a technology contest: "LoRaWAN or NB-IoT?" This article's argument: that framing itself asks the wrong question.

The real question is: under the three constraints (cannot remove, cannot modify, should not replace), how do you bring in-service installed assets online? Under those constraints:

Data profile routes first (video to 4G/5G, metering to LPWAN);
Device distribution picks the path (clustered → private network, scattered → operator);
Target assets pick the form (RS-485 installed base → DTU route, new points → native sensors);
Power condition picks the model (AC cabinet / DC cabinet / no-supply points).

And technology selection is only the entry ticket. What decides whether a project lives to year five is engineering detail beyond the datasheet: cable that does not embrittle at -40°C, a 0.8% packet-loss rate next to a VFD, a wide-voltage design that draws power directly in the distribution cabinet, and remote upgrade capability that frees protocol adaptation from on-site debugging.

The next decade of industrial digitalization will be fought not in brand-new smart factories but in legacy sites where "the equipment has more seniority than the engineers." Whoever completes the last mile with the lowest invasiveness holds the ticket to this market.

Appendix A: Glossary

Term	Definition
LPWAN	Low-Power Wide-Area Network; umbrella term for LoRaWAN/NB-IoT/Sigfox/Wi-SUN
DTU	Data Transfer Unit; protocol-conversion terminal between serial devices and wireless networks
Modbus RTU	Master-slave serial industrial protocol running on the RS-485 physical layer
DL/T 645	Chinese power-industry standard protocol for multi-function electricity meters
CJ/T 188	Chinese urban-construction standard protocol for household metering instruments (water/gas/heat)
COV	Change of Value; do not upload unchanged data
FUOTA	Firmware Update Over The Air for LoRaWAN
CSS	Chirp Spread Spectrum; the LoRa physical layer, resistant to narrowband interference
ADR	Adaptive Data Rate
EB (EdgeBus)	ManThink's event-driven edge-computing VM; written in TypeScript, runs low-power on MCUs
Installed base	The retrofit market of already-deployed, mostly wired-interface devices
SIL	Safety Integrity Level

Appendix B: References

HMS Networks, Industrial Network Market Analysis 2026 — Ethernet 79% / fieldbus 14% / wireless 7% of new nodes; PROFINET 30%, Modbus TCP 5%, Modbus RTU 3%
LNS Research / ARC Advisory / McKinsey 2025 manufacturing benchmarks — ~70% of installed industrial control assets older than 15 years
QYResearch, Global Industrial DTU Market Research Report 2026 — $709M (2025), $750M (2026), $1,052M (2032), CAGR 5.8%, average price $102, ~6.95M units/year
360iResearch / Data Insights Market, Industrial Wireless DTU Market — $1.37B (2025), CAGR 8.85%
NiceRF, "LoRa, LoRaWAN, NB-IoT, and 4G DTU: Industrial Wireless Solution Selection Analysis" — four-technology comparison and three selection cases
KaaIoT, NB-IoT vs LoRaWAN: which to use for industrial IoT applications? — CAPEX/OPEX structures, coverage behavior, interference immunity
VolleyBoast, Using VoBo in Noisy Industrial Environments — CSS interference immunity and deployment discipline in industrial EMI
Robustel, How to Choose an Industrial LoRaWAN Gateway for Harsh Environments — failure-mode analysis of "hidden harsh" indoor environments
AnyPCBA industrial gateway case — 15% → 0.8% packet loss in high-interference mining sites; 68% TCO reduction over three years
Yunzhibian pharmaceutical cold-storage case study — 470 MHz penetrating 20 cm insulation; -80°C cable-embrittlement lesson
ThinkLink official documentation — KC11/KC25/KC21 DTU specifications, EdgeBus architecture, ManThink company positioning (www.think-link.net)
ManThink, "How to Quickly Connect Traditional RS485 Devices to a LoRaWAN Network" — RS-485 installed-base integration architecture

The LPWAN Market in 2026: LoRaWAN vs NB-IoT vs Sigfox

manthink — Fri, 11 Sep 2026 01:59:05 +0000

From "three-way race" to "one retreat, one hold, one advance" — Sigfox has restructured after bankruptcy, NB-IoT leans heavily on the Chinese market, and LoRaWAN runs away with the private-network segment overseas. The 2026 LPWAN story is not about displacement; it is a marathon between three business models.

1. The Short Version

If you only have 30 seconds to understand the 2026 LPWAN landscape, remember three things:

NB-IoT holds the largest connection count, but it is highly dependent on China — roughly 84% of global NB-IoT connections are in China. Exclude China, and the picture changes completely.
LoRaWAN leads overseas markets and China's private-network segment — LoRa Alliance figures show more than 125 million deployed end devices growing at about 25% per year; outside China, LoRaWAN holds roughly 41% of LPWAN connections, the largest single share.
Sigfox has exited mainstream competition — after its 2022 receivership and acquisition by Singapore's UnaBiz for about €25 million, it was rebranded as "Sigfox 0G Technology" and now plays a supporting role in a multi-protocol convergence strategy, no longer a standalone track.

Research firms disagree widely on total LPWAN connection counts (from roughly one billion to several billion, depending on whether Chinese metering, LTE-M, and private LoRa networks are counted), but the directional conclusion is consistent: NB-IoT and LoRa together account for about 83% of the LPWAN market — a stable duopoly — while Sigfox has retreated into a niche.

2. Technology Profiles

2.1 LoRaWAN: The Open-Ecosystem Private-Network Champion

Foundation: Semtech's LoRa physical layer (chirp spread spectrum) plus the MAC-layer protocol maintained by the LoRa Alliance. It operates in Sub-GHz unlicensed spectrum (EU868, US915, CN470, AS923, etc.) with a star topology and a four-tier architecture: end device — gateway — network server (NS) — application server.

Key parameters:

Data rates of 0.3–50 kbps (DR0–DR5 in EU868); payloads up to ~242 bytes depending on DR
AES-128 end-to-end encryption with OTAA dynamic joining
Class A/B/C device types; battery life of 8–10 years is achievable
ADR (adaptive data rate) plus LR-FHSS long-range frequency hopping for dense deployments

Market position (LoRa Alliance 2025 End of Year Report):

More than 125 million deployed end devices, growing at roughly 25% annually
Around 360 alliance members, with 57 added in 2025
LoRa-family technologies hold roughly 64% of smart-building deployments — precisely because private networks don't depend on operators
The LoRaWAN connectivity market is projected to grow from about US$10.7B in 2025 to about US$44.8B by 2030 (~33% CAGR)

Moat: You can build the network yourself. One open-source gateway (such as the ManThink GD6, with tri-path backhaul and a full protocol stack) plus an open-source NS (ChirpStack) gets you a private network where data never leaves your campus. No cellular technology offers that.

2.2 NB-IoT: The Licensed-Spectrum Regular Army

Foundation: A cellular narrowband technology standardized in 3GPP Release 13 (2016), running in licensed spectrum with a carrier bandwidth of only 200 kHz — deployable in-band, in guard band, or standalone within LTE.

Key parameters:

Peak downlink ~26 kbps; uplink ~15.6 kbps single-tone (higher multi-tone)
Relies on operator base-station coverage; coverage depth roughly 20 dB better than legacy GSM (MCL 164 dB)
Power-saving via PSM, eDRX, and PSA mechanisms
Continued evolution in 3GPP Rel-17/18, with NTN satellite connectivity validated

Market position:

About 84% of global NB-IoT connections are in China, driven by carrier base-station upgrades since 2017 and the policy-backed migration of water and gas metering
NB-IoT and LTE-M together reached roughly one billion active connections by the end of 2025
NB-IoT accounts for roughly 54%–58% of total LPWAN share (with China's weight included)

Moat: The operator network. No gateways to deploy or maintain — insert a SIM card and coverage is the carrier's problem. The price: subscription fees, carrier lock-in, and uncertainty around network sunsetting cycles.

2.3 Sigfox: From Unicorn to "0G Technology Brand"

Foundation: Ultra-narrowband (UNB) modulation with channels only 100 Hz wide, ~100 bps uplink, 12-byte payloads, and a message budget of 140 uplinks and 4 downlinks per day. Radical simplicity buys radical low power and rock-bottom silicon cost.

Rise and fall:

Founded in 2010; peaked at a valuation of about US$1 billion, once mentioned alongside LoRaWAN and NB-IoT as one of the three LPWAN schools
Filed for receivership in January 2022; acquired by Singapore's UnaBiz in April for roughly €25 million (retaining 110 of 174 employees)
UnaBiz's plan was never to "revive Sigfox" but to pursue multi-protocol convergence: rebranded as "Sigfox 0G Technology," it became one option in UnaBiz's LPWAN abstraction layer alongside LoRaWAN, LTE-M, and Wi-SUN — exemplified by Japan's Nicigas gas-metering project, where 90% of sensors use Sigfox and 10% use Cat-M for coverage gaps

Today: The 0G network covers 70+ countries and over a billion people, with roughly 20 million devices still in service. It retains unique value in ultra-low-cost asset tracking (single-use logistics trackers, cold-chain tags). But the narrative of Sigfox as a mainstream rival to LoRaWAN and NB-IoT is over.

3. The 2026 Market in Numbers

Counting methodologies vary across research firms; sources are cited for cross-reference:

Dimension	Figure	Source
LoRaWAN deployed end devices	125M+, ~25% annual growth	LoRa Alliance 2025 EOY Report
LoRa Alliance membership	~360 (57 added in 2025)	LoRa Alliance
NB-IoT geographic concentration	~84% of connections in China	IEEE ComSoc Technology Blog (2026.3)
LPWAN share outside China	LoRaWAN ~41%, #1	IEEE ComSoc Technology Blog (2026.3)
Long-range IoT connectivity revenue (2025)	NB-IoT ~$6.2B (43.5%), LoRaWAN ~$4.5B (31.8%), LTE-M ~$2.1B (14.9%), Sigfox & others ~$1.4B (9.9%)	PW Consulting market report
LoRaWAN connectivity market forecast	~$10.7B (2025) → ~$44.8B (2030), 33.1% CAGR	Industry forecast (cited by IEEE ComSoc)
Duopoly concentration	NB-IoT + LoRa ≈ 83% of LPWAN	IoT Analytics (baseline, structure persists)
Sigfox/0G network	70+ countries, ~20M devices in service	Sigfox/UnaBiz official

Three cautions when reading these numbers:

"LoRa" and "LoRaWAN" are not the same count. Cumulative LoRa chipset shipments (700M+) far exceed LoRaWAN protocol connections (125M) — many proprietary-protocol devices also use the LoRa PHY.
China's weight inverts conclusions. Include China and NB-IoT is the runaway leader; exclude it and LoRaWAN leads overseas. Global product planning must split the markets.
Revenue share ≠ connection share. NB-IoT's revenue share (~43%) is lower than its connection share (~54%–58%) because many Chinese metering connections carry very low ARPU.

4. Three Dividing Lines

Dividing line 1: China vs. the rest — two parallel markets

China is NB-IoT's home turf: carrier-led base-station coverage and policy-driven metering migration (smart water/gas meter penetration above 80% in tier-1 cities) make NB-IoT the default in public utilities.

Overseas markets (Europe, North America, Southeast Asia, Latin America) never saw comparable carrier NB-IoT investment. LoRaWAN took roughly 41% of connections there on the strength of private networks and an open ecosystem, with growth led by smart buildings, smart agriculture, asset tracking, and campus deployments.

For product companies: in China, plan for NB-IoT and LoRaWAN coexisting; globally, LoRaWAN's ecosystem advantage is more pronounced.

Dividing line 2: The Sigfox lesson — great technology is not a great business

Sigfox's UNB technology remains unmatched on ultra-low power and ultra-low cost. Why did it fall?

Closed ecosystem: Chip supply, base stations, and the cloud were all controlled by one company; partners could only act as distributors — a stark contrast to the LoRa Alliance's 360-member open model
Single business model: Selling connectivity alone, without end-to-end vertical solutions, stalled growth in an industry that demands solutions
Capital mismatch: The heavy-asset "build the network first, find customers later" model burned out over IoT's long adoption cycle

UnaBiz's post-acquisition pivot answers each lesson: no more single-technology evangelism, but an LPWAN abstraction layer that mixes networks by coverage, cost, and use case. "Customers don't care which LPWAN they use — they care about getting devices online at a sensible cost." Every IoT professional should keep that sentence.

Dividing line 3: Convergence is the 2026 theme

The LPWAN market is moving from "picking sides" to "combining":

Amazon Sidewalk: a consumer-grade LoRa-based shared network already covering 95% of the US population, expanding into Canada and Mexico in 2026 — Big Tech chose the LoRa PHY as the foundation for mass consumer IoT
Hybrid networking as the norm: 1NCE (cellular) and Netmore (LoRaWAN) announced integrated global coverage; UnaBiz's 0G abstraction spans Sigfox/LoRaWAN/LTE-M
Satellite NTN for coverage gaps: 3GPP Rel-17/18 takes NB-IoT to direct-to-satellite; the LoRa camp's LR1121 chipset supports Sub-GHz + 2.4 GHz + satellite S-band
LoRaWAN keeps evolving: LR-FHSS lifts dense-deployment capacity by an order of magnitude, and the 2025 Regional Parameters update tripled the top data rate

5. An Engineer's Selection Guide

Decision dimension	Choose LoRaWAN	Choose NB-IoT	Choose Sigfox/0G
Deployment model	Self-built private network	Operator network	Operator network (70+ countries)
Data sovereignty	Fully yours	Data transits carrier	Data transits carrier
Max payload	~242 B	~1600 B (theoretical)	12 B
Downlink capability	Weak (Class A) / strong (Class C)	Fairly strong	Very weak (4 msgs/day)
Mobility / handover	Weak (designed for static nodes)	Moderate	Weak
Traffic cost	CAPEX + zero fees	SIM subscription	Subscription (lowest)
Entry threshold	One gateway is enough	Depends on carrier coverage	Depends on carrier coverage
Ecosystem openness	Open alliance, 360+ members	3GPP standard, operator-led	Single-vendor technology (UnaBiz-operated)
Typical use cases	Buildings, campuses, agriculture, factories	City-scale metering, municipal assets	One-way tracking, cold-chain tags

Three questions for a quick decision:

Does data need to leave your site? No → LoRaWAN private network; Yes → next question
Is there stable operator coverage at the deployment site? Yes, and the project is urban → evaluate NB-IoT; No (remote, basement, cross-border) → LoRaWAN or hybrid
Uplink-only, 12 bytes per message enough, cost squeezed to the limit? Yes → evaluate Sigfox/0G; No → back to the first two questions

A pragmatic trend is dual-mode hybrid: LoRaWAN collects campus sensors at the access layer while backhaul runs over 4G/Ethernet; or core assets use NB-IoT for guaranteed coverage while high-density sensing uses LoRaWAN for cost control. ManThink's GD6 gateway does this at the hardware level — LoRaWAN access plus Ethernet/Wi-Fi/4G tri-path backhaul, one device filling both network roles.

6. The ManThink Perspective: The Engineering Dividend of Private Networks

As a device vendor in the LoRaWAN camp, our read of the landscape is direct: LoRaWAN's long-term value lies in connecting the installed base.

A huge share of sensors in industrial and building environments are wired (RS-485, M-Bus, 4-20mA, DI/DO). When retrofitting them for wireless, operator networks are neither economical nor controllable. A LoRaWAN private network lets integrators expand their sourcing from "LoRaWAN-interface sensors only" to "any wired sensor," completing retrofits at low cost with a gateway plus wireless conversion modules (such as Edge-Bus architecture DTUs).

That is why GD6 exists as an open-source gateway and ThinkLink as a lightweight NS plus application platform: once the connectivity market settled into a duopoly, the real competition moved to lowering the entry barrier for private networks — a network in five minutes, template-based sensor onboarding, event-driven low-power edge logic. The market data backs this direction: the main engine of LoRaWAN's 25% annual growth is precisely private and enterprise-built networks.

7. Conclusion

The 2026 LPWAN market has no winner-take-all outcome:

NB-IoT wins on carrier infrastructure and Chinese metering — the "public-utility-grade" choice
LoRaWAN wins on open ecosystem, private deployment, and overseas markets — the "enterprise-autonomy-grade" choice
Sigfox lost its standalone track, but its UNB technology lives on as "0G" inside a multi-protocol convergence ecosystem

For engineers and decision-makers, the question was never "which technology is better" but "which route fits your data sovereignty, deployment environment, and cost structure" — and increasingly, the right answer is a combination, not a side.

References

_1. LoRa Alliance 2025 End of Year Report (Feb 2026) — 125M devices, 360 members

IEEE ComSoc Technology Blog (Mar 2026) — NB-IoT share 54%–58%, China ~84% of global NB-IoT, LoRaWAN ~41% outside China
PW Consulting, Worldwide Long Range IoT Connectivity Market 2026 — revenue share by technology
Light Reading, "Sigfox rescued from receivership by Singapore's UnaBiz" (Apr 2022) — receivership and acquisition details
Stacey on IoT, "UnaBiz has a nice plan for Sigfox" — 0G convergence strategy and the Nicigas case
Sigfox/UnaBiz official site — 0G network coverage data
IoT Analytics — 83% duopoly baseline (historical)
ThinkLink knowledge base — ManThink market positioning and product line_

# LoRaWAN Device Classes: Class A, B, and C Compared — A Selection Guide

manthink — Fri, 28 Aug 2026 07:42:19 +0000

Introduction: Why do water meters, streetlights, and gateways look different on the same network?

Open the datasheet of any LoRaWAN device and you will find a line item: Device Class. Water meters say Class A. Smart streetlights might be Class B. Relay cabinets and gateways are Class C.

These letters are not marketing labels. They are the LoRaWAN specification's three conventions for how a device receives downlink data — and they directly determine:

how long the device can run on a battery;
how quickly it receives commands sent by the platform;
how you should plan power supply and maintenance for the project.

One sentence captures the essence: in LoRaWAN, uplink is easy, downlink is expensive. Sending data is cheap for a device; but to "always hear the platform talking," the radio receiver must stay on — and a receiver's power draw is typically a hundredfold or more above deep sleep. Class A/B/C are the protocol's three answers to this conflict.

This article explains all three mechanisms and gives you a selection table you can use directly in your next project.

1. First, understand the conflict: why is downlink so hard?

LoRaWAN is a low-power wide-area network (LPWAN). Its typical endpoint is a battery-powered sensor, with a design goal of "one battery lasting 5–10 years."

To achieve that, the device must spend the vast majority of its life in deep sleep — and a sleeping device is deaf. It cannot hear any call from the gateway. If the platform must be able to send commands at any time (remote switch-off, changing the reporting interval), the receiver has to stay on continuously, and battery life immediately shrinks from "a decade" to "a few months."

Power consumption and downlink responsiveness are natural adversaries. Class A, B, and C are not three "technologies" — they are three compromise points along this axis: from "spend nothing on downlink" (A), to "wake up on a schedule to check for commands" (B), to "always online" (C).

2. Class A: Listen only after speaking — the lowest-power baseline

Mechanism: the two receive windows

Class A is the mandatory baseline for all LoRaWAN devices — whatever class a device claims, it always implements Class A behavior first.

The logic is simple: the device sleeps deeply and only briefly opens two receive windows after it has sent an uplink:

Device      ──uplink──►  Gateway/NS
              │
              │ wait RECEIVE_DELAY1 (default 1 second)
              ▼
            RX1 window opens (brief)
              │ if nothing, wait another second
              ▼
            RX2 window opens (brief)
              │ if still nothing
              ▼
            back to deep sleep

RX1: opens about 1 second after the uplink ends, typically on the same (or similar) frequency and rate as the uplink;
RX2: follows about 1 second later, using the region's fixed frequency and rate (e.g., EU868's RX2 is fixed at 869.525 MHz / DR0; check your Regional Parameters).

Both windows are short; once closed, the device returns to sleep. In other words, the network can only reach a Class A device by "hitching a ride" — it must wait for the device to speak first. Downlink payloads queue at the NS until the next uplink opens RX1/RX2.

Characteristics and use cases

Dimension	Performance
Power	Lowest of the three; deep sleep dominates
Downlink timing	Only after uplink; cannot be woken on demand
Downlink latency	Bound by reporting interval: hourly reports → up to ~1 hour wait
Typical supply	Primary battery (lithium), life of 8–10 years achievable

Use cases: water/gas/electricity meters, temperature/humidity and soil sensors — anything that is "sense and report, with almost no downlink." This is why Class A dominates the LoRaWAN sensor ecosystem.

3. Class B: Scheduled listening — the middle ground

Mechanism: Beacon sync + Ping Slots

Class B adds a "wake up on schedule and take a look" mechanism on top of Class A:

Beacon synchronization: gateways periodically broadcast Beacons; after receiving one, the device aligns with network time — from then on, it "knows what time it is."
Ping Slots: with time sync in place, the device briefly opens a receive window at periodic fixed moments (Ping Slots), listening for downlink addressed to it. Nothing? Back to sleep. Something? Receive and process.

The Ping Slot period is configurable (the specification defines several tiers from seconds up to 128 seconds): shorter period → more responsive downlink, but more wake-ups and higher power.

        After Beacon sync, the device's timeline:
  ──┬────┬────┬────┬────┬──►
    │    │    │    │
  Ping  Ping  Ping  Ping      ← scheduled brief windows
  Slot  Slot  Slot  Slot
   (awake for milliseconds, deep sleep the rest)

Characteristics and use cases

Dimension	Performance
Power	Slightly above Class A (Beacon reception + Ping Slot wake-ups)
Downlink timing	Can be scheduled into Ping Slots; no longer fully dependent on uplink
Downlink latency	Bounded: at worst one Ping Slot period
Deployment requirement	The network side must support Beacon broadcast — gateway and NS both; not something a device can do alone

Use cases: smart streetlights (seasonal on/off schedules pushed remotely), devices needing periodic time sync, monitoring points that must receive downlink within minutes. Class B is comparatively rare in practice, largely because of this deployment threshold: the whole chain (device–gateway–NS) must support it.

4. Class C: The "real-time mode" — for mains-powered devices

Mechanism: receiving everything except while transmitting

Class C abandons the "sleep to save power" idea altogether: the radio receiver stays on almost continuously, closing only for the instant of uplink transmission (to avoid self-jamming), then immediately returning to receive mode.

  ──RX──RX──RX──│TX│──RX──RX──RX──RX──►
              (receiver off only while transmitting)

With this, commands from the platform arrive almost instantly — downlink latency drops from "minutes/hours" to "seconds."

The cost: power is dominated by RX current

This is the account every engineer must run. A radio receiver typically draws milliamps to tens of milliamps, while a Class A device in deep sleep draws microamps — three to four orders of magnitude apart.

There is a well-established engineering conclusion (not a protocol prohibition): Class C is generally unsuitable for primary-battery devices. A primary cell (e.g., lithium thionyl chloride) cannot sustain continuous RX current; without a complete power-lifecycle budget, no multi-year lifetime claim is credible.

Hence Class C's typical supplies: mains power, PoE, or large rechargeable batteries.

Dimension	Performance
Power	Highest of the three; average current dominated by RX
Downlink timing	Anytime, near real-time
Downlink latency	Seconds
Typical supply	Mains / PoE / always-on

Use cases: relays and control cabinets (remote switching), industrial real-time monitoring, actuators — and LoRaWAN gateways themselves (a gateway, as an "always-on" device, is naturally Class C in behavior).

5. Side-by-side comparison

Dimension	Class A	Class B	Class C
Receive timing	RX1/RX2 after uplink only	Uplink windows + periodic Ping Slots	Continuous except while transmitting
Downlink capability	Weakest (rides on uplink)	Scheduled, bounded latency	Near real-time
Downlink latency	Next uplink (minutes–hours)	At worst one Ping period (seconds–minutes)	Seconds
Power	Lowest	Slightly above A	Highest (RX-dominated)
Typical supply	Primary battery	Battery (capacity uprated accordingly)	Mains/PoE
Battery-life magnitude	5–10 years	Years (depends on Ping period)	Not applicable to primary batteries
Network-side requirements	None special	Gateway + NS must support Beacons	None special
Typical devices	Utility meters, temp/humidity sensors	Smart streetlights	Relays, actuators, gateways

One point worth emphasizing: the device class does not change regional data-rate definitions, nor can it bypass local transmission regulations — it is a MAC-layer receive-behavior convention, independent of the physical-layer parameters (SF/BW/CR — see Article 4 in this series).

6. Selection: ask yourself three questions

Question 1: Does this device need to receive downlink commands?

Almost never (report-only) → Class A, no hesitation.
Yes, but waiting minutes is fine → see Question 2.
Yes, with second-level response (control) → Class C, and plan mains/PoE supply.

Question 2: Is the device battery-powered?

Yes, and must last 5+ years → Class A; if periodic downlink is genuinely required, evaluate Class B and budget the power carefully.
Mains/always-on → Class C is available; enjoy real-time downlink.

Question 3 (for Class B): Does the infrastructure support it?

Do the gateway and NS support Beacon broadcast? Without it, Class B exists only on paper.

A practical rule of thumb: sensors default to Class A, actuators default to Class C, and consider Class B only for the middle ground. This matches the product mix you see across most LoRaWAN vendors today.

7. Three common misconceptions

Misconception 1: "Class C is more advanced — pick it and you're safe."

Class C is not an upgrade; it is a different trade-off. Configuring a battery sensor as Class C means burning its battery on RX current — lifetime drops from a decade to months, while also consuming gateway downlink capacity. Choosing the wrong class costs more directly than choosing the wrong SF.

Misconception 2: "Class A devices can never receive downlink."

False. A Class A device receives downlink in the RX1/RX2 windows after every uplink — ACKs, MAC commands, and configuration changes all fit in these windows. Only the timing is tied to uplink. In practice, with a sensible reporting interval and command queuing, Class A handles most configuration-delivery needs.

Misconception 3: "Class is baked into the device and cannot change."

Class is MAC-layer behavior. Many devices (especially configurable DTUs and modules) support Class A/C switching, letting you choose dynamically by project phase: Class C during commissioning for real-time provisioning, back to Class A in production for power savings. Just make sure the switching logic matches the power supply.

8. Engineering practice tips

Power budget first: whatever the class, run the power-lifecycle estimate first (RX/TX/sleep current × time share), then pick battery capacity — especially for Class B and C. "Back-of-envelope lifetime promises" are the top source of after-sales disputes.
Trim downlink requirements: audit every "needs real-time downlink" requirement. Many so-called real-time controls degrade gracefully to "deliver configuration on next report" — which Class A satisfies.
Mind the downlink bottleneck: a typical gateway has 8 channels and 16 demodulators — 16 parallel uplink packets but often only a single downlink channel. Many Class C devices plus frequent downlink will squeeze that resource; plan downlink traffic density accordingly.
Activation is special: during OTAA, the Join Accept itself is delivered in RX1/RX2 — even Class C devices follow Class A timing during activation. This is yet another reflection of A being the baseline.

Conclusion

Class A/B/C are, at their core, three lines LoRaWAN draws between "low power" and "downlink responsiveness": A pushes power to the minimum and queues the downlink; B trades time synchronization for bounded downlink latency; C trades mains power for second-level response.

Once you internalize this main axis, you can look at any LoRaWAN device's class label and immediately infer its power supply, downlink capability, and appropriate use cases — a skill more valuable than memorizing any parameter.

Written by the ManThink technical team. ManThink is committed to open-source and reliable LoRaWAN infrastructure: the GD6 open-source gateway (ESP32-S3 + SX1302) supports global bands and mainstream network servers, and the in-house EdgeBus edge-computing engine supports Class A/C mode switching to connect sensors to LoRaWAN at minimal power.

LoRa Physical Layer Parameters: How SF, BW, and CR Shape Range and Data Rate

manthink — Wed, 26 Aug 2026 01:37:51 +0000

Introduction: Same sensor, but 2 km for one team and 15 km for another?

A recurring puzzle in LoRaWAN projects: identical sensors and gateways, yet one customer reports "coverage of only 2 km" while another claims "we reach 15 km." Antennas and mounting aside, the most overlooked cause is the configuration of three LoRa physical-layer parameters — Spreading Factor (SF), Bandwidth (BW), and Coding Rate (CR).

LoRa's core design philosophy is "trading bandwidth for distance." Unlike WiFi or 4G, which chase high throughput, LoRa spreads the signal so the receiver can demodulate it at much lower signal-to-noise ratios. But how much spreading, and how, is governed by SF, BW, and CR.

This article explains these parameters thoroughly: what each one is, how it affects range and data rate, the concrete numbers, and how to make trade-offs in real projects.

1. SF (Spreading Factor): The "gear" for range

What is the spreading factor

The Spreading Factor (SF) defines how many chips (chirp symbols) each data bit is expanded into. Each step up in SF doubles the number of chips per symbol:

At SF12, each data bit is represented by 4096 chips — the signal is "spread out" 32 times relative to SF7. The receiver can therefore pull it out of the noise at much weaker signal levels, and the communication range grows accordingly.

Why larger SF means longer range

A larger SF brings two direct benefits:

Lower (more negative) receiver sensitivity. SF7 sensitivity is roughly −124.5 dBm; SF12 reaches about −137 to −141 dBm (values vary slightly with link-budget assumptions). Every 3 dB of sensitivity gain roughly doubles the theoretical range.
Higher processing gain. The spread signal is stretched in time, and correlation demodulation at the receiver yields processing gain, improving robustness against interference.

The cost is rate and airtime: larger SF means lower data rate and longer time-on-air per packet.

How fast is each tier, really

Measured with the calculation engine (BW = 125 kHz, CR = 4/5):

From SF7 to SF12, the rate drops by nearly 19×. That is the physical-layer conflict between "long range" and "high throughput" made concrete.

One common point of confusion: although larger SF means longer symbol duration, different SFs are orthogonal — signals on different SFs can coexist on the same channel without interfering. This orthogonality is exactly why a gateway can demodulate multiple SF streams concurrently.

2. BW (Bandwidth): The "accelerator" for rate

What is modulation bandwidth

Bandwidth (BW) is the actual frequency span occupied by the LoRa signal. The most common setting in LoRaWAN is 125 kHz, with 250 kHz and 500 kHz also available.

The relationship with data rate is straightforward: doubling BW halves the symbol duration and doubles the rate. Measured (SF7, CR = 4/5):

Combination	PHY data rate
SF7 / 125 kHz	≈ 5.47 kbps
SF7 / 250 kHz	≈ 10.94 kbps

But there is no free lunch: a wider BW also widens the receiver's noise bandwidth, raising the noise floor, degrading sensitivity, and shortening range. BW is an "accelerator" — floor it and you gain speed but lose endurance (range).

How BW is used in LoRaWAN

The vast majority of regional DR0–DR5 definitions are based on 125 kHz;
Some regions (e.g., EU868) define DR6 as SF7 / 250 kHz, as a higher-rate tier;
The 500 kHz tier rarely appears as a device data rate in the LoRaWAN standard; it is more common in gateway uplink test scenarios.

3. CR (Coding Rate): The "insurance" for reliability

What is the coding rate

The Coding Rate (CR) is the forward error correction (FEC) redundancy ratio in LoRa, with four possible values:

What it does

CR lets the receiver recover the original data even when some bits are corrupted by interference. The worse the signal and the more interference, the more redundancy is needed. The cost: lower effective rate and longer time-on-air — each extra redundancy bit reduces coding efficiency.

The LoRaWAN standard defaults to CR = 4/5 (coding rate offset 1), which already provides good anti-ber capability at the highest effective rate. In practice, CR is rarely the parameter you tune day-to-day, but understanding it helps diagnose issues like "why is my over-the-air time longer than estimated."

4. LDRO: The overlooked fourth parameter

When a single symbol lasts longer than 16 ms (typical in low-rate scenarios such as SF11/SF12 with 125 kHz), long transmissions can cause crystal oscillator frequency drift that affects demodulation. In that case, Low Data Rate Optimization (LDRO) should be enabled, adding redundancy bits in the header to combat clock drift.

Note: LDRO is not a coding rate. It does not change rate calculation itself; it is simply a reliability switch for low-rate scenarios. Most LoRaWAN stacks (including the Semtech reference implementation) set LDRO automatically based on SF and BW, so manual intervention is rarely needed.

5. Quantified comparison: Time-on-air for a 13-byte packet

Time-on-air directly determines channel occupancy and battery life — arguably the single most important number for a project. Measured with the calculation engine (13-byte payload, CR = 4/5, explicit header):

Combination	Time-on-air	Ratio vs SF7
SF7 / 125 kHz	≈ 46.3 ms	1×
SF12 / 125 kHz	≈ 1155.1 ms	≈ 25×

The same temperature/humidity reading takes 46 ms at SF7 but 1.15 s at SF12 — a 25× difference. For battery-powered devices, this means:

Under duty-cycle limits, SF12 devices can transmit far less frequently per hour;
Power consumption rises (longer RF transmit time);
Channel occupancy at the gateway grows, reducing network capacity.

Industry capacity estimates confirm this: on the same 8-channel gateway with the same reporting interval, a network of all-SF7 devices can theoretically host 20× more nodes than an all-SF12 network (different models give SF7 ≈ 787k vs SF12 ≈ 29k devices; exact figures depend on the assumed SF distribution, but the conclusion is consistent).

6. Real-world trade-offs: Why there is no "best" setting

Put SF, BW, and CR together, and the core problem is a four-corner trade-off:

Want range → raise SF (e.g., SF12), lower BW;
Want throughput → lower SF, raise BW;
Want reliability → raise CR;
Want low power / high capacity → use low SF and short packets.

You cannot win all four at once. This is exactly why LoRaWAN designed ADR (Adaptive Data Rate) — the network side measures the actual signal quality received by gateways and automatically assigns each device the most suitable SF: good signal → drop to SF7 for higher rate, lower power, and freed-up channels; weak signal → move up to SF11/SF12 to protect coverage. ADR is the most cost-effective way to resolve the range-vs-rate dilemma.

Two common engineering misconceptions

Mistake 1: Locking everything to SF12 for coverage.

The sensitivity advantage of SF12 is real, but the cost is a three-way hit to rate, power, and capacity. The right approach: let ADR adapt first, then pin high SF only for the few weak-signal devices — never a network-wide one-size-fits-all.

Mistake 2: Assuming chip support means LoRaWAN support.

Chip capability ≠ protocol capability. For example, the SX1262 radio supports SF5, but the current LoRaWAN Regional Parameters do not define SF5/SF6 as standard data rates — devices cannot join using SF5. SF selection must satisfy both "chip support" and "Regional Parameters definition."

7. Configuration recommendations for project teams

Default to ADR: enable ADR after join so the network adapts SF to real signal conditions — the best return on effort.
Tier by use case: allow SF10–SF12 for long-range reporting (remote agriculture, mountain monitoring); push dense urban deployments (smart buildings) down to SF7–SF9.
Keep packets small: a LoRaWAN frame maxes out at 255 bytes, but airtime grows linearly with payload — don't send 50 bytes when 13 will do. Data compression and change-of-value (COV) reporting significantly extend battery life.
Budget airtime up front: before deployment, calculate device airtime × transmit frequency and check against regional duty-cycle limits (e.g., EU868's 1% rule) to avoid running out of channel capacity later.
Validate in the real environment: theoretical sensitivity differences ≠ field coverage differences. Metal structures, foliage, and terrain all take their toll — a field test across SFs is the most reliable check.

Conclusion

SF, BW, and CR are the three knobs of the LoRa physical layer. They determine how far, how fast, and how reliably the same radio hardware can communicate. Understanding them lets you make deliberate trade-offs among range, rate, power, and capacity — instead of being carried away by "LoRa transmits far."

The good news for LoRaWAN developers: the network side (NS) and ADR already automate most of the tuning. Your job is to understand the principles, set the boundaries, and let the system find the balance.

Written by the ManThink technical team. ManThink is committed to open-source and reliable LoRaWAN infrastructure. Its GD6 open-source gateway (ESP32-S3 + SX1302) covers CN470 / EU868 / US915 / AS923 and other global bands, with ADR, OTA, and support for mainstream network servers.

LoRaWAN Device Activation Explained: OTAA vs ABP

manthink — Mon, 17 Aug 2026 08:44:16 +0000

Before a LoRaWAN device can send or receive any data, it must complete a process called activation — the step where the device obtains its network address and session keys. The activation method you choose affects security, deployment complexity, and day-to-day operations.
The LoRaWAN specification defines two activation methods: OTAA (Over-The-Air Activation) and ABP (Activation By Personalization). This article breaks down how each works, compares them side by side, and gives practical selection guidance.

OTAA: Over-The-Air Activation

OTAA is the recommended activation method. Devices ship without session keys and complete authentication over the air after the first power-up.

How It Works

OTAA activation happens in three steps:

1. The device sends a Join Request

The device transmits a Join Request carrying:

The Join Request is authenticated with a MIC (Message Integrity Code) computed using the AppKey, ensuring the message was not tampered with.

2. The network server validates and sends a Join Accept

On receiving the Join Request, the network server:

Looks up the device's AppKey (and NwkKey on LoRaWAN 1.1) by JoinEUI/AppEUI
Verifies the MIC to confirm message integrity
Checks the DevNonce to prevent replay (each DevNonce can only be used once)
On success, assigns a DevAddr (32-bit device network address)
Generates a Join Nonce (network-server-side random value)
Builds and encrypts a Join Accept message with the AppKey The Join Accept carries:

3. The device derives its session keys

The device decrypts the Join Accept with its AppKey, then derives session keys from the AppKey, JoinNonce, DevNonce, and NetID.
LoRaWAN 1.0.x (1.0.2 / 1.0.3 / 1.0.4) derives two keys:

NwkSKey (Network Session Key): MIC computation for MAC-layer messages and MAC command encryption
AppSKey (Application Session Key): application payload encryption Simplified derivation:

LoRaWAN 1.1 introduces key separation, deriving four keys:

FNwkSIntKey: Forward Network Session Integrity Key
SNwkSIntKey: Serving Network Session Integrity Key
NwkSEncKey: Network Session Encryption Key
AppSKey: Application Session Key LoRaWAN 1.1 renames AppEUI to JoinEUI and separates the NwkKey from the AppKey, enabling network-level and application-level key separation — the foundation for secure roaming.

OTAA Security Properties

Keys never travel over the air: AppKey/NwkKey are provisioned on the device and network server; session keys are derived independently on both sides. Only the encrypted Join Accept crosses the air interface.
DevNonce replay protection: each DevNonce can be used exactly once; servers track used values.
Key rotation: a device can re-join at any time to obtain fresh session keys.
Roaming support: LoRaWAN 1.1's key separation design enables cross-network roaming.

ABP: Activation By Personalization

ABP skips the join procedure entirely. Devices are pre-provisioned with all communication parameters at manufacture and start sending immediately after power-up.

What Is Pre-Provisioned

The following must be written to the device before shipping and registered on the network server in advance:

ABP devices do not need a DevEUI, JoinEUI, or AppKey (unless you plan to migrate to OTAA later).

How It Works

An ABP device goes straight to work after power-up:

Uses the pre-configured DevAddr as its source address
Computes MICs with NwkSKey and encrypts MAC commands with NwkSKey
Encrypts/decrypts application data with AppSKey
Starts transmitting on default channels There is no Join Request / Join Accept handshake.

The Frame Counter Problem

ABP devices must manage their uplink (FCntUp) and downlink (FCntDown) frame counters. Network servers track these counters to prevent replay attacks — if a device reboots and its counter resets below the value the server last recorded, its frames will be rejected.
Two common approaches:

Server-side reset: reset the device's frame counters manually on the platform (fine for debugging)
Device-side persistence: store counters in non-volatile storage and resume from the last value after reboot (required for production)

OTAA vs ABP: Side-by-Side

| Dimension                    | OTAA                                                           | ABP                                                                                 |

| ---------------------------- | -------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
| Security | High — keys derived over the join procedure, never transmitted | Low — keys must be written at manufacture and registered server-side; exposure risk |
| Key rotation | Yes — re-join to obtain fresh keys | No — keys are fixed; changing them requires reflashing devices |
| DevAddr assignment | Dynamically assigned by network server | Fixed at manufacture; uniqueness must be managed manually |
| Deployment complexity | Device only needs root keys; server handles the rest | Both device and server need full pre-configuration |
| Time to first packet | Join procedure first (typically 5–15 seconds) | Instant — works right after power-up |
| Frame counter management | Starts from zero after join; no conflict issues | Must be managed carefully; reboot may cause rejected frames |
| Roaming | Supported (LoRaWAN 1.1 key separation) | Not supported |
| LoRaWAN 1.1 | Fully supported — 1.1 relies on OTAA | Not recommended under 1.1 |
| Deployment scale | Suitable for production fleets | Suitable for small tests |
| Network switching | Change JoinEUI to join another network | Requires reflashing all parameters |

Which One Should You Use?

Use OTAA when

Production deployments — any fleet beyond a handful of devices should be OTAA
Security matters — sensitive data or compliance requirements
Large scale — DevAddr is dynamically assigned, avoiding conflicts
Roaming is needed — cross-network or multi-region deployments
LoRaWAN 1.1 networks — 1.1's security features depend on OTAA

ABP is acceptable when

Development and debugging — validate device communication quickly without the join handshake
Teaching and demos — simplify the flow so students focus on data exchange
Very small, fixed deployments — one or two devices in a controlled environment with low security requirements
Uplink-only scenarios — devices only transmit, with minimal key-management needs (still weigh the security trade-off)

A Common Misconception

"ABP saves power because there's no join procedure."
Not really. The join procedure costs very little — one Join Request and one Join Accept, typically completed in a few seconds. Compared to a device's multi-year battery life, the energy of the join phase is negligible. What ABP actually saves is development-time configuration effort — and in production that convenience comes at the cost of lower security and higher operational overhead.

Practical Notes

OTAA in Practice

DevEUI must be globally unique: use an IEEE EUI-64 derived from the device MAC; never hardcode a default value
Store AppKey securely: it's the root key — compromise means the device's entire communication can be decrypted. Prefer a secure element, or at least the MCU's flash encryption
Persist DevNonce: it must live in non-volatile storage and keep incrementing across reboots. A rollback causes the network server to reject Join Requests
Implement join retry with backoff: avoid hammering the channel if the network is temporarily unreachable
Listen in the join windows: Join Accept arrives in RX1 (default 5 s) and RX2 after the Join Request; the device must be listening

ABP in Practice

Persist frame counters: store FCntUp and FCntDown in non-volatile storage (RTC backup registers, flash, or EEPROM)
Plan DevAddr carefully: the 7-bit NwkID must match the network server's NetID; the 25-bit address must be unique within the network
Protect keys in manufacturing: ABP keys are written at manufacture — keep them out of production logs and test records
Never commit keys to public repos: if you share code on GitHub or similar, don't hardcode NwkSKey and AppSKey

Working with the ThinkLink Platform

On ThinkLink:

OTAA devices: register DevEUI and AppKey on the platform; the device joins automatically after power-up
ABP devices: register DevAddr, NwkSKey, and AppSKey; the device communicates immediately
The platform shows join status and frame counters for every device
If a frame counter conflict occurs, reset it from the device management page

Summary

Bottom line: use OTAA in production, ABP only for debugging and teaching. If you have more than ten devices, or if devices sit in environments you can't physically control, OTAA is the only sensible choice.
Written against the LoRaWAN 1.0.4 and 1.1 specifications. Protocol details follow the LoRa Alliance specification documents; operational advice draws from ThinkLink platform experience.
ThinkLink is the IoT platform product from ManThink, providing LoRaWAN network management, device operations, and data services.

ManThink Launches GD6 Open-Source LoRaWAN Gateway: ESP32-S3 + SX1302 Indoor Solution

manthink — Thu, 06 Aug 2026 02:14:32 +0000

ManThink has officially released the GD6 (GD61x series), an open-source indoor LoRaWAN gateway. The gateway is built around an ESP32-S3 MCU with an optional Semtech SX1301 or SX1302 concentrator, integrating Ethernet, Wi-Fi, and optional 4G multi-link backhaul. It covers major LoRaWAN regional bands worldwide — including CN470, EU868, AS923, and US915 — supports the full protocol stack (UDP Packet Forwarder, MQTT Bridge, and Basic Station), and delivers its complete web configuration system and firmware management capabilities as an open-source platform.

GD6 is positioned as a cost-effective indoor LoRaWAN gateway for developers, system integrators, and IoT solution providers. It is suitable for smart buildings, campus networks, small industrial sites, prototyping, and academic research.

Design Philosophy

Building a LoRaWAN gateway is not primarily a hardware challenge — the SX1302 + ESP32 combination is well-established. The real challenge lies in balancing "works out of the box" with "deeply customizable."

Most commercial gateways lock their configuration systems inside closed apps or cloud backends, limiting the parameters developers can tune. Pure DIY solutions offer flexibility but lack engineered configuration workflows and reliable OTA mechanisms, making them difficult to deploy in production.

GD6 takes a different approach: the hardware is designed and manufactured to commercial standards, but the configuration system, management interfaces, and firmware upgrade mechanisms are fully open. You can unbox a GD6, connect the antenna and power, and have it online in 5 minutes through the web interface. At the same time, you can integrate it into your own operations stack via REST API and remote MQTT, or even build and flash custom firmware.

It's a gateway that works out of the box — and can also be taken apart and modified.

Hardware

GD6's hardware design centers on three goals: sufficient performance, deployment flexibility, and convenient power.

MCU: ESP32-S3-WROOM-1 (N8R8)

8 MB QIO Flash + 8 MB Octal PSRAM, both running at 80 MHz. The ESP32-S3's dual-core processor handles multi-channel LoRa transceiving while simultaneously running the web console, TLS-encrypted communication, and MQTT remote configuration. The 8 MB PSRAM ensures the gateway doesn't drop packets or lag under high channel load.

LoRa Concentrator: SX1301 or SX1302

GD6 offers two concentrator options, identified directly by the model suffix:

Suffix 1: Semtech SX1301 — the classic solution, mature and stable
Suffix 2: Semtech SX1302 — lower power consumption, higher sensitivity

Both use an A-type LoRa architecture: single LoRa antenna, 8 frequency channels, 65 sub-channels, half-duplex.

RF Versions: Covering Major Global Bands

The 4 and 8 in the model number indicate the RF frequency range, not the number of channels. The region code must match the RF hardware and local regulations — you cannot convert a gateway from one frequency band to another through software alone.

Backhaul: Ethernet + Wi-Fi + Optional 4G

Ethernet: W5500, 10/100 Mbps, RJ45, supports DHCP or static IP
Wi-Fi: ESP32-S3 integrated 2.4 GHz, supports AP + STA concurrently
4G (optional): LTE Cat 1, miniPCIe interface, module is swappable for different carrier bands

Ethernet is the default priority link; when the primary link fails, the gateway automatically switches to the backup. Models with 4G (indicated by G in the model number) have triple-link backhaul; models without 4G (indicated by N) have dual-link.

The Wi-Fi AP mode operates independently of the backhaul link, providing a local configuration and recovery entry point. The default hotspot SSID is LGW-Config, password lgw12345678, management address 192.168.4.1.

Power Supply: Three Options

Type-C 5V: convenient for desktop debugging
DC terminal 5–24V: wide-voltage input for industrial sites

PoE (AG configuration only): power and data over a single RJ45 cable

Connecting multiple power sources simultaneously is not recommended.

Protocol Support

GD6 supports three mainstream uplink protocols, covering virtually all LoRaWAN network servers:

Semtech UDP Packet Forwarder — The classic protocol with the broadest compatibility. Configure the server address, uplink/downlink ports, and timeout parameters to connect.

MQTT Bridge — Forwards LoRa data via MQTT, supporting mutual TLS, CA certificates, and client certificates. Suitable for enterprise deployments with data security requirements. The MQTT Bridge uses an independent connection that does not interfere with the remote configuration channel.

Basic Station — Semtech's recommended next-generation gateway protocol, supporting LNS direct connection or CUPS bootstrap. Authentication options include TLS + Token or mTLS (client certificates). Compatible with TTN/TTI, ChirpStack, and other major network servers.

All three protocols are switched from the "LNS Configuration" page in the web console. Switching the uplink driver triggers a gateway reboot — confirm no OTA or configuration write is in progress before switching.

Open Source: What's Open

GD6's firmware and web configuration system are open-sourced on GitHub: github.com/ManThink/gd6-open.

The open-source design spans several layers:

Complete Web Configuration System
A bilingual (Chinese/English) web console covering network backhaul, LoRaWAN server, RF parameters, system logs, firmware upgrades, file system management, and user management. All configuration items are exposed via REST API for programmatic management.

Independent Remote MQTT Configuration Channel
Through a dedicated MQTT connection, you can remotely read and write permitted configuration items and trigger reboots without physical device access. This channel is completely independent from the data-forwarding MQTT Bridge, using separate connections and credentials. To prevent lockout from remote misconfiguration, the remote channel cannot modify its own Broker settings. Suitable for large-scale gateway operations.

A/B Dual-Partition OTA
GD6 uses an A/B dual firmware partition design. During upgrades, new firmware is written to the inactive partition, verified, and then the boot partition is switched. Even if an upgrade is interrupted or fails, the device boots from the original partition — no bricking. Firmware .bin files can be built independently and flashed via the web interface.

Accessible File System
Configuration files under /spiffs can be viewed and managed from the web console. Configuration JSON takes effect after reboot, supporting deep customization. Note: the web/ directory's static files should not be modified carelessly — overwriting them may render the console inaccessible, and a factory reset will not restore them.

Configuration Workflow

From power-on to online, the process typically takes under 5 minutes:

Power up: Connect the LoRa antenna (antenna must be connected before power-on), then power via Type-C or DC terminal
Connect to the gateway:

Via Ethernet: find the gateway address in your router's DHCP list, open it in a browser
Via Wi-Fi: connect to the LGW-Config hotspot, navigate to http://192.168.4.1

Log in: use the default password wifi!0804, then change it immediately in User Management
Configure backhaul: set up network connection on the "Ethernet" or "Wi-Fi" page
Configure LNS: select the uplink protocol on the "LNS Configuration" page, enter the network server address and port
Set frequency band: confirm the region and sub-band on the "Frequency & RF" page, apply, and restart the LoRa service

No serial cable needed, no command line required. If a configuration error makes the web console inaccessible, the REC button performs a factory reset — hold for 2 seconds, the device resets and reboots. Network and LoRaWAN configurations are restored to defaults; the written Gateway EUI is preserved.

Application Scenarios

Smart Buildings & Campuses
GD6's indoor design and Wi-Fi backhaul suit office buildings and industrial parks. A single gateway can cover one floor of LoRaWAN devices — temperature/humidity monitoring, personnel positioning, energy management. Ethernet provides stable backhaul; Wi-Fi serves as backup.

Small Industrial Sites
The 5–24V wide-voltage power input adapts to industrial power conditions. Models with 4G can deploy in warehouses and workshops without wired network infrastructure, using 4G as primary or backup link. The miniPCIe 4G module is swappable for local carrier bands.

Development & Prototyping
The ESP32-S3's performance and open-source configuration system make GD6 suitable as a LoRaWAN development platform. Developers can manage gateways in bulk via REST API, customize configurations through the file system, and quickly set up test environments to verify device communication.

Education & Research
Universities and research institutions can use GD6 to build LoRaWAN lab environments. Students can explore gateway internals through the web console and file system rather than facing a closed black-box device.

Multi-Region Global Deployment
GD614 and GD618 cover major global frequency bands, and the 4G module is swappable by region — suitable for cross-regional project deployment. The region code in the model number clearly identifies the supported LoRaWAN regional parameters.

Technical Specifications

Model Numbering

GD6 model format: GD61{4|8}-A{N|G}-{Region}-{Version}-{1|2}:

Example: GD618-AG-AS923-N-2 = 800 MHz+ RF, with 4G and PoE, AS923 region, default version, SX1302 concentrator.

Integration with ThinkLink Platform

GD6 is the native gateway hardware for the ThinkLink IoT platform. When used with ThinkLink, you can register gateways with one click and auto-sync Gateway EUI, visually manage devices, thing models, and automation rules through the platform, remotely push configurations without on-site visits, and monitor gateway status and backhaul links in real time.

At the same time, GD6's full protocol stack support means you're free to connect to any third-party LoRaWAN network server — TTN/TTI, ChirpStack, LoRiot, or a self-hosted LNS are all compatible.

Learn More

GD6 Open-Source Repository (firmware + web config): github.com/ManThink/gd6-open
GD61x Specifications & User Guide: think-link.net/docs/zh/Device/LoRaWANGateway/gd61x-user-guide
GD6 Configuration Guide: think-link.net/docs/zh/Device/LoRaWANGateway/gd6-configuration-guide
ThinkLink Platform Website: www.think-link.net
ManThink Website: www.manthink.cn

ManThink — Making IoT development more efficient.

ThinkLink Integrated Device Library: No Device Left Behind — Retrofitting Starts with a Search

manthink — Tue, 21 Jul 2026 01:55:52 +0000

Covering 29+ verified field devices across metering, industrial sensing & control, building & environment, and smart agriculture. Search by name, model, or protocol — every device comes with complete integration documentation.

Why a "Device Catalog"?

In IoT projects, the hardest part isn't the technology itself — it's figuring out "can I connect this device?"

The client's site has a Schneider Electric power meter with Modbus RTU. Can it go LoRaWAN?
A heating retrofit project uses CJ/T 188 heat meters on an M-Bus. How do you take them wireless?
An Acrel multi-circuit power meter — how many circuits per collector? In the traditional LoRaWAN ecosystem, answering these means: digging through sensor datasheets, scouring ChirpStack codec repositories, writing your own parsing scripts — every step costs time.

ThinkLink's Integrated Device Library was built to solve exactly this.

Device-First Search Logic
The core philosophy is simple: don't start from platform features — start from what's in the field.
Open https://www.think-link.net/zh/devices/ and you'll see a clean search interface:

Search by device name — type "ADW2xx" or "three-phase meter", go straight to the target
Filter by model — exact model matching supported
Filter by protocol — Modbus RTU / DL/T 645 / CJ/T 188 / native LoRaWAN, at a glance No need to understand ThinkLink's architecture first. No need to know what EdgeBus is. Whatever device you're holding, start there.

Four Categories Covering Mainstream Retrofitting Scenarios

1. Metering (11 devices)

Covers the most common meter types for building energy monitoring and heating/water metering.

2. Industrial Sensing & Control (12 devices)

Industrial sites are characterized by diverse device types, inconsistent protocols, and harsh environments. The library covers the complete sensing chain from temperature, level, and RPM to oil spill detection, with KC11/KC21 collectors providing a unified RS-485-to-LoRaWAN access layer.

3. Building & Environment (5 devices)

4. Smart Agriculture (1 device, packed with capability)

A single KC21 supports up to 3 soil sensors, covering multi-dimensional farmland sensing in one deployment.

Three Access Paths, One Card Tells the Whole Story

Every device card on the library shows not just the name, model, category, and protocol — it also labels the access path:

And every device card comes with complete integration documentation. Click "View Integration Guide" on any card and you'll jump directly to that device's step-by-step manual, which covers:

Wiring diagrams (which wire goes to which KC collector terminal)
EdgeBus configuration (function codes, register addresses, data formats)
Thing model parsing scripts (pre-written JS parsing logic)
Parameter configuration tables (upload interval, read interval, COV thresholds, slave address)
Key caveats (e.g., DL/T 645's +0x33 offset encoding, CZ580's register unlock command)

More Than a List — It's an Integration Decision Tool

The library's value goes beyond "looking things up" — it helps integrators make technical decisions:

Scenario 1: A client says "We have Acrel ADW2xx meters and want energy monitoring."
→ Search the library → Confirm Modbus RTU protocol → Open the integration guide → Learn that 1 KC21 handles 1 ADW2xx with 4 circuits uplinked independently → Assess feasibility in under 10 minutes.

Scenario 2: A heating retrofit project has Jingquan LXSY-15E cold water meters on site.
→ Search "CJ188" → Confirm KC22 + M-Bus + EdgeBus access → The guide provides complete frame format, data identifiers, and thing model parsing → No need to dig through the CJ/T 188 national standard.

Scenario 3: Comparing a weighing transmitter vs. ultrasonic level sensor for the right fit.
→ Search both devices → Compare accuracy, response time, power requirements, and integration complexity from the documentation → Make an informed selection based on actual parameters.

A Growing Device Ecosystem

ThinkLink's device library is not static. Every time a new device is validated for integration, its documentation is added. The library currently covers:

Protocols: Modbus RTU, DL/T 645-2007, CJ/T 188-2004, native LoRaWAN
Collectors: KC11 (220 VAC powered, Class C), KC21 (battery powered, IP65), KC22 (M-Bus dedicated)
Brands: Schneider Electric, Acrel, ZENNER, Huizhong, Elitech, Renke, Zhuowen, Disen, Dianyingpu, Shenling, GXHY, Tianwei, Ringder, and more

If you have a device not yet listed, ThinkLink's EdgeBus framework supports rapid adaptation. Using EBHelper's JSON configuration or EBSDK's TypeScript scripting, most Modbus RTU devices can be protocol-adapted and added to the library within 30 minutes.

Conclusion

The ThinkLink Integrated Device Library is more than the number "29 verified devices." Its real value lies in:

Lowering the technical evaluation barrier — integrators don't need to become LoRaWAN experts first; just look up the device by name to know if it works
Shortening project startup time — the complete path from wiring to data-on-platform is already documented for every device
Eliminating repeated trial-and-error — DL/T 645 offset encoding, M-Bus parity settings, sensor-specific unlock commands — all battle-tested knowledge is baked into the docs, no need to rediscover it on every project Start from the device, not the platform. That's ThinkLink's answer to the IoT retrofit market.

DEV Community: manthink

The Five-Layer Funnel for LoRaWAN Troubleshooting: From "No Data in the Cloud" to "The Numbers Are Wrong"

1. The funnel at a glance

2. Layer 1: Is the gateway online

Read the three time fields together

Three definitions of "online," not interchangeable

If the gateway is offline, separate "no power" from "no network"

3. Layer 2: Did the gateway hand frames to the NS

4. Layer 3: Did the NS decrypt successfully

NS has data, AS is empty: only three possibilities

FPort is more than a business category

5. Layer 4: Did the thing model parse it

AS has data, realtime data is empty: only two causes

Three fixed traps in the script layer

6. Layer 5: Where did the data go

Egress 1: the raw retention switch

Egress 2: the forward whitelist

Egress 3: the subscriber's own problems

False empties introduced by paginated loading

7. The on-site trio: diagnosing without the platform

One: the gateway's local web console

Two: an MQTT client

Three: a site visit you can actually price

8. Seven traps from real integration work

9. Compressing the funnel into 20 minutes

10. What this method actually solves

Further reading

Official documentation

LoRaWAN Gateway Antenna Selection and Installation Guide: Why 3 dBi Sometimes Beats 8 dBi

1. Start with the band: the wrong antenna is the first line on the trouble ticket

2. Three things that matter more than the gain number

The unit trap: dBi vs dBd

Gain is not amplification, it is redistribution

VSWR measures how much energy never leaves

Polarization: twenty dB or more, silently

3. The link budget: account for every decibel

Free-space path loss

Real environments replace n

A worked example

4. Feeder cable: the easiest 3 dB to throw away

5. Antenna height matters more than antenna gain

6. Verify uplink and downlink separately

7. Selecting by scenario: five typical combinations

8. Ten installation steps, straight from the manuals

Four points on waterproofing

Where to mount it — and where not to

9. Six things you must not do

10. Commissioning: how to read RSSI and SNR

11. One page for the field team

Conclusion

Further reading

Official manuals

Connecting ThinkLink to Home Assistant and Node-RED: One MQTT Forwarder Does the Whole Job

1. Start with a version change: the built-in HA integration is gone

2. Three possible paths — pick the right one before you start

3. The forwarder: two steps, five fields

Step 1: create two broker connections

Step 2: create the forwarder rule

How to fill in Subscription Topic

4. The transform script: translating ThinkLink into HA's vocabulary

5. Home Assistant: two ways in

6. Node-RED: three nodes and you are running

7. Writes: from HA / Node-RED back to the device

8. Online status: one switch you have to turn on yourself

9. After 2.00.070: do not just watch for RUNNING

10. Troubleshooting: work this order

11. Acceptance checklist

12. Closing

Connecting ThinkLink to BACnet/IP and Modbus TCP: From Field Mapping to YABE Verification

1. Scope First: BACnet and Modbus Are TKE / TKG Only

2. What This Segment Actually Costs: The Industry Prices by the Point

3. BACnet vs Modbus: You Are Delivering Objects, or You Are Delivering Addresses

4. BACnet in Five Steps, in This Order

Step 1 — the system administrator enables the service permission

Step 2 — configure the BACnet fields in the thing model

Step 3 — enable BACnet on the device

Step 4 — generate the point table

Step 5 — configure service parameters and restart

5. Three Point-Table Constraints With Long Reach

1. object_id runs 0–4194303, and renumbering changes what the integrator is using

2. `data_from` is free text, not an enum