Device mode
Pick what this device should do. This sets the mesh role and the RS485 behaviour for you — you don't need to know the LoRa Mesh role names. Finish the details on the linked tab, then Apply device mode.
Applies the mesh role immediately and saves the RS485 behaviour to the device. The Radio and Channel tabs are separate — set those with Save settings.
Radio — Taiwan / NCC
Locked to region TW + 500 kHz bandwidth — the single-channel BW500 LoRa config that qualifies under NCC (FCC 15.247 DTS). Set the exact centre frequency in 920–925 MHz and the spreading factor. All nodes on one mesh must match.
0x34 (LoRaWAN's "public" value) instead of Meshtastic's upstream default
0x2b — a deliberate Siliqs design choice so the Siliqs LD1002 LoRaWAN
gateway can receive these nodes. As a result, these nodes cannot join the public
Meshtastic network — different sync words can't hear each other.
Primary channel
The channel name + PSK are your mesh's private identity — every node (all field nodes and the gateway) must use the same name and PSK to hear each other.
LongFast is the LoRa Mesh
public default preset (BW250 / SF11). The SQC485I uses a custom TW · BW500
radio (see the Radio tab), so it cannot interoperate with public LongFast nodes —
reusing that name only causes confusion. Give your mesh its own name
(default BW500SF9, after the radio config) so it's clearly your private network.
Default key = the LoRa Mesh well-known public key — fine for bench testing but not secret (anyone can decrypt it). For a real deployment pick Custom and share that PSK only with your own nodes.
Bluetooth security (BLE pairing)
Controls how a phone or PC pairs with this node over BLE. On the BLE-only hardware this is the device's main access control — anyone who can pair can read and re-configure it, so set a PIN you keep private.
Random PIN (the LoRa Mesh default) shows a fresh code on a screen at each connection — this board has no screen, so it isn't offered here. Pick a Fixed PIN for real use; No PIN only on a trusted bench.
BLE transmit power
Higher power = more BLE range but more battery (and more 2.4 GHz EIRP). Applied live and saved on the device; no reboot, no re-pairing.
Modbus forward config (field nodes)
The read plan the node forwards as raw bytes on PortNum 256. Per-poll type / word-order / scale / unit are cloud-decode metadata — not sent over the air.
Turn off for a node with no RS485 sensor wired — it stops polling (no more slave-error reads). The poll list below is kept but not used until you re-enable. (Gateways don't poll regardless.)
From a vendor Modbus PDF? Build the template JSON with your AI agent →
Copy this prompt into your AI agent (ChatGPT / Claude) along with the device's Modbus register table or PDF — it returns a template JSON in the right schema. Paste it below and Load. (Verify any guessed word-order / scale on the bench.)
Where the node sends its reads. Broadcast = every node on the channel; pick a node (e.g. your gateway) to unicast only to it. Channel index 0 = primary; use a higher index only if you've set up that secondary channel. Set a destination quickly from the Nodes page.
| Name | Slave | FC | Reg | Count | Type | Word | Scale | Unit |
|---|
↻ Edit any field above to tune the AI's output — the cfg blob + cloud spec below rebuild live (and flash) on every change, and Push sends these current fields, not the original JSON. Note: Type / Word / Scale / Unit are cloud-decode metadata — editing them changes the Cloud decoder spec only, not the device blob (the device just forwards raw bytes). Slave / FC / Reg / Count / Baud / Interval change the blob.
cfg blob (PortNum 256 payload)
—
Cloud decoder spec
—
Pushed to this device only (sent to "self" on PortNum 256). The node validates the blob (magic + CRC) and re-inits its UART immediately.
Test the read
Push the config first, then Test now: the node reads its RS485
bus immediately and returns the raw frame, decoded here per your poll list (type / word-order
/ scale / unit). Also updates from the node's periodic reads. func & 0x80 = a
read error (sensor not wired / wrong baud / wrong slave).
RS485 terminal (manual send / read)
Manually send a frame (Hex or Text) onto an RS485 bus through the connected node and read whatever the slave replies — handy for probing a meter. Target the connected node (its own RS485), or a remote node over the mesh (it reads its own RS485 and the reply comes back over LoRa). Works the same whether you connected over USB or BLE.
Driving the connected node — its reply returns straight to here (no LoRa).
RS485 ↔ RS485 tunnel (wireless RS485 extender)
Bridge two RS485 buses over LoRa so they act as one long wire. A master (PLC / SCADA / any RS485 device) wired to this node's RS485 talks through to a slave on the remote node's RS485 — frames are forwarded raw both ways (any protocol, not just Modbus). This setting is saved on the device: it boots straight into tunnel mode.
At low baud increase the idle gap (a byte takes longer), or whole frames may be split. 20 ms suits ≥ 4800 baud.
Saved in the device config (blob v4) and applied immediately — no reboot needed. To stop tunnelling, untick and Apply again (the node returns to normal polling).
Modbus tunnel (collector answers as a Modbus slave)
Lets an external Modbus master poll this gateway for the readings other mesh nodes send it, instead of parsing raw mesh traffic itself. The gateway needs to know each node's poll plan (order + slave / function / register) to slice its cached raw bytes back into registers — so the row list below is required for both modes, not just aggregated.
| Source node | Slave | FC | Reg start | Reg count | Virtual offset |
|---|
Saved in the shared device config (blob v5) and applied immediately — no reboot needed.
Live telemetry (standard Meshtastic EnvironmentMetrics)
Temperature & humidity this node reports as standard Meshtastic telemetry (PortNum 67) — the very data any Meshtastic app or MQTT bridge reads — shown live off this connection. Updates on the report interval (default 60 s), so the first reading can take up to a minute.
Nodes
Every node this device has heard on the mesh (its node DB) — updates live.
direct = a direct neighbour; N hops = reached via relays.
| Name | Link | Last heard | SNR | RSSI | Model | Node ID | |
|---|---|---|---|---|---|---|---|
| Connect to a node to see the mesh… | |||||||