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 Meshtastic 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.
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 Meshtastic's
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 = Meshtastic's 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 (Meshtastic's 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).
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 | Model | Node ID | |
|---|---|---|---|---|---|---|
| Connect to a node to see the mesh… | ||||||
Gateway (host-side bridge & telemetry)
This page is not the device you connect over USB/BLE above — it embeds the siliqs-mesh-bridge control panel running on your gateway machine (the always-on box that forwards mesh telemetry to MQTT). Point it at that machine and configure / watch it here.
Examples: http://localhost:9090 (same machine) ·
http://192.168.0.9:9090 (the linxdot appliance). Remembered in this browser.
Note: if this configurator is served over https://, browsers block embedding a
plain http:// gateway — open it in a new tab instead.